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ABSTRACT 

The  Federal  goverrment  depends  upon  software  systems  to 
fulfill  its  missions.  These  software  systems  must  be  main¬ 
tained  and  improved  to  continue  to  meet  the  growing  demands 
placed  on  them.  The  process  of  software  maintenance  and 
improvement  may  be  called  "software  evolution".  The  soft¬ 
ware  manager  must  be  educated  in  the  complex  nature  cf  soft¬ 
ware  maintenance  to  be  able  to  properly  evaluate  and  manage 
the  software  maintenance  effort.  In  this  thesis,  the 
authors  explore  software  maintenance  from  a  management 
perspective,  highlighting  topics  of  critical  importance. 
These  topics  include  forecasting  software  maintenance,  esti¬ 
mating  the  resources  required  to  perform  software  mainte¬ 
nance,  managing  maintenance  personnel  and  effectively 
utilizing  software  tools.  The  synthesis  of  these  topics 
forms  a  managerial  paradigm  for  understanding  the  evolu¬ 
tionary  nature  of  software  maintenance. 
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I.  INTRODUCTION 

A.  B  AC  KGROOND 

The  f edera 1  government  for  the  last  twenty  to  thirty 
years  has  become  more  and  more  reliant  on  computer 
processing  to  accomplish  its  seemingly  ever  increasing  and 
complex  missions.  In  1955,  when  the  trend  started,  hardware 
was  the  overriding  concern,  consuming  85%  of  the  total 
computing  dollar  [Ref.  1:  p.  18].  Since  that  time,  however, 
dramatic  improvements  in  technology  and  production  have 
substantially  decreased  the  cost  of  computer  hardware. 
Software,  on  the  other  hand,  has  not  benefitted  from  techno¬ 
logical  advancements  to  the  same  degree  as  hardware  and  has 
continued  to  rise  in  price  relative  to  hardware.  The  rise 
in  the  price  of  software  and  the  decrease  in  the  price  of 
hardware  has  resulted  in  software  rapidly  becoming  the  mere 
costly  of  the  two.  It  is  predicted  that  by  1985  software 
costs  will  dominate  hardware  costs  by  a  ratio  of  nine  to  one 
[Ref.  1:  p.  18],  The  true  impact  of  this  trend  becomes 
significant  when  one  realizes  that  the  annual  cost  of  soft¬ 
ware  (development  and  maintenance)  in  the  United  States  in 
1980  was  about  $40  billion,  or  about  2%  of  the  Gross 
National  Product  [Hef.  1:  p.  17].  It  is  predicted  that  by 
1985  annual  software  costs  will  reach  $200  billicn  [Ref.  1: 

p.  18]. 

A  significant  share  of  these  costs  are  for  software 
maintenance.  Various  studies  have  shown  that  from  forty  - 
to  -  seventy  percent  of  the  manpower  effort  in  most  ADP 
activities  is  dedicated  to  software  maintenance  [Ref.  1,  2, 
3].  Despite  its  monetary  significance,  there  is  as  yet  no 
universally  agreed  upon  definition  of  software  maintenance. 
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The  extensive  research  dene  cn  software  development  and  on 
the  management  of  the  development  process  is  oniy  now  begin¬ 
ning  to  have  its  counterpart  in  the  field  of  software  main¬ 
tenance.  The  underlying  nature  and  causes  of  software 
mainterance  are  still  imperfectly  understood  by  management 
at  all  levels,  military  and  industry.  The  reasons  for  this 
lack  of  understanding  [Hef.  4:  p.  2-12]  include: 

1.  Executive  decision  makers*  lack  of  computer  related 

experience:  for  a  manager  overseeing  software  main¬ 

tenance  this  lack  of  experience  is  often  demonstrated 
through  impatience  with  system  limitations  and  intol¬ 
erance  for  the  costs  of  system  enhancements. 

2.  Hardware  orientation  of  software  management  mecha¬ 
nisms:  Host  directives  and  techniques  for  control¬ 

ling  the  development  and  maintenance  of  software  have 
been  adopted  from  hardware  engineering  disciplines. 
Thus,  quality  assurance,  reliability  and  maintain¬ 
ability,  and  configuration  management  procedures 
reflect  an  orientation  toward  tangible  products. 
Their  translation  for  use  vitn  the  environment  of 
intangible  software  components  has  not  been  a 
completely  successful  one. 

3.  Development  vice  life  cycle  focus:  This  has  signifi¬ 
cant  impact  on  the  tasks  of  managing  and  maintaining 
software  after  development.  Computer  programs  that 
are  developed  in  the  most  expeditious,  cost-ef fectuve 
way  to  meet  performance  standards  are  not  necessarily 
conducive  to  maintainability.  Often  the  development 
project  manager  must  sacrifice  software  design 
features  that  are  conducive  to  program  maintain¬ 
ability  in  order  to  meet  cost,  schedule  or  perform¬ 
ance  requirements.  Thus  the  user  is  left  with 
software  that  is  costly  to  maintain. 
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5. 


6. 


7. 


Increased  software  system  complexity:  Complexity  is 

not  inherently  bad  for  maintenance  if  introduced  in 
moderation  and  if  doc umenta tion  is  adequate.  In 
today's  data  processing  environment  there  is  less 
need  than  ever  before  for  complex  designs  and  elegant 
cede.  Considering  the  increasing  costs  of  software 
development  and  maintenance  it  makes  more  sense  to 
produce  straightforward  program  logic  and  code. 
"Low-bid"  contracting  for  acquisition  of  a  software 
system:  This  situation  affects  maintenance  indi- 

rectly  as  a  result  of  the  efforts  of  any  cost  cutting 
on  the  part  cf  the  developer.  Given  the  degree  to 
which  DoD  contracts  its  software  development,  this 
problem  has  significant  impact  on  the  military. 

Kisk,  cost  and  reliability  estimating  deficiencies: 
Accurate  estimation  techniques  would  greatly  enhance 
the  maintenance  managers  effectiveness  in  allocating 
resources  for  program  maintenance 

Absence  of  Common  Software  Maintenance  Practices: 
Management  at  all  levels  are  placed  in  the  awkward 
position  of  having  to  learn  to  interpret  management 
control  data  from  each  new  system. 


B.  PBCBIEH  DISC0SSIC8 


This  thesis  will  study  software  maintena 
management  perspective.  Primary  emphasis  will 
examining  pertinent  aspects  of  the  management  o 
tion  of  software  maintenance.  The  thesis  will  f 
maintenance  activity  itself,  rather  than  on  t 
between  the  activity  and  the  users  of  software, 
meat  of  that  interface  is  termed  "Configuration 
and  is  well-governed  with  numerous  policies  an 
The  majority  of  existing  software  configuratio 


nc 

e  f  r 

cm 

a 

be 

plac 

ed 

on 

f 

the 

fu 

nc- 

oc 

us  on 

the 

he 

inte 

rf 

ace 

The  ma 

na 

ge- 

Ma 

nagem 

en 

t". 

d 

stand 

ar 

ds . 

n 

manag 

em 

en  t 

12 


doctrine  focuses  on  software  development#  while  providing 
little  assistance  to  the  software  maintenance  manager.  The 
authors  do  not  intend  to  present  a  "how-to"  manual  for  soft¬ 
ware  maintenance;  rather#  a  framework  will  he  offered  upon 
which  tie  manager  may  develop  his  or  her  understanding. 

A  central  premise  of  this  thesis  is  that  software 
evolves.  The  concept  of  software  evolution  has  teen 
explored  in  the  literature  before  [Eef.  5:  p.217]  and 
provides  the  basis  for  a  paradigm  with  which  a  software 
manager  may  understand  the  nature  and  causes  of  software 
maintenance. 

Software  evolution  is  influenced  by  a  number  of  internal 
and  external  factors.  External  factors  define  the  environ¬ 
ment  to  which  a  given  software  system  must  adapt,  and 
internal  factors  define  the  ability  of  the  system  to  make 
the  adaptation.  The  goal  of  the  software  manager  is  to 
direct  the  evolution  of  the  software  toward  a  system  that 
continues  to  meet  organizational  goals,  or  at  least  away 
from  a  system  that  is  inefficient  and  expensive. 

The  software  manager  must  seek  to  understand  the  factors 
that  influence  software  evolution  in  order  to  achieve  the 
goal  of  directing  that  evolution.  By  understanding  these 
factors#  he  or  she  may  then  learn  to  predict  their  influence 
on  software  evolution.  Once  the  influence  of  the  internal 
and  external  factors  may  be  predicted#  the  software  manager 
may  then  seek  to  control  those  factors  and  direct  the  evolu¬ 
tion  of  the  software  system. 

A  failure  of  the  manager  to  even  understand  how  and  why 
software  evolves  will  allow  the  software  system  to  evolve  in 
an  uncontrolled  fashion  towards  a  morass  of  inflexible  and 
unreliable  "spaghetti"  code.  Controlling  the  evolution  of 
software  allows  the  software  manager  to  maintain  a  func¬ 
tioning#  effective  software  system  well  into  the  future. 


Software,  like  ary  evolving  entity,  nay  reach  ar  evolu¬ 
tionary  dead-end.  This  occurs  when  the  internal  factors 
(code  structure  and  design)  make  it  impossible  to  respond  to 
the  evolutionary  demands  of  external  factors.  Software  in 
this  stage  may  be  said  to  have  achieved  "software  senility". 

Tte  intent  of  this  thesis  is  to  help  the  software 
manager  understand  what  factors  influence  software  evolu¬ 
tion,  hew  to  predict  software  evolution,  and  finally,  seme 
ideas  on  how  to  control  the  influence  of  internal  and 
external  factors. 

C.  GEKEBAL  PROCEDURE 

The  procedure  used  was  to  research  literature  concerning 
software  maintenance.  Particular  emphasis  was  placed  on 
software  maintenance  management,  cost  estimation,  and  meth¬ 
odologies  to  conduct  software  maintenance.  The  personal 
experience  of  LT  Sullivan  was  invaluable  in  placing  much  of 
the  research  in  perspective. 

D.  0 EG A BIZ ATI OH 

Chapter  II  develops  a  definition  of  software  mainte¬ 
nance,  and  discusses  the  major  activities  conducted  during 
maintenance.  The  similarities  of  software  maintenance  to 
software  development  and  the  characteristics  of  the  mainte¬ 
nance  phase  of  the  software  life  cycle  are  also  discussed. 
Considerations  in  predicting  required  software  maintenance 
are  explored  in  Chapter  III,  and  the  data  required  to  accu¬ 
rately  predict  software  maintenance  is  discussed  in  Chapter 
IV.  In  Chapter  V,  methods  of  estimating  software  mainte¬ 
nance  costs  are  presented,  and  problems  associated  with 
current  estimating  techniques  are  discussed.  Chapter  VI 
explains  in  more  detail  personnel  consideration  in  software 
maintenance,  and  Chapter  VII  explores  the  impact  of  software 


tools  and  standards.  The  relationship  of  software  mainte¬ 
nance  and  data  is  the  subject  of  Chapter  VIII.  Chapter  IX 
summarizes  the  authors'  views  on  software  maintenance, 
explains  a  paradigm  with  which  a  software  manager  may  better 
understand  software  maintenance. 
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II.  SOFTWARE  MAINTENANCE  DEFINED 

A.  TEE  NATURE  OF  SOFTWARE 

Software  may  be  defined  as  "a  realization  of  a  set  of 
plans  or  specifications,  encoded  in  computer  language." 
[Ref.  6:  p.  7].  Software  is  not  a  physical  entity,  it  is  an 
abstraction,  a  logical  representation  that  is  physically 
manifested  in  the  fora  of  program  listings  and  documenta¬ 
tion.  Software,  unlike  hardware,  does  not  wear  out. 
Hardware  is  subject  tc  deterioration  in  the  course  cf  ncriral 
operation  and  requires  maintenance  in  order  to  restore  it  to 
its  former  operating  condition.  Software,  on  the  ether 
hand,  dees  not  change  unless  and  until  people  change  it. 
Software  does  not  wear  out  of  its  own  accord.  Software 
maintenance  does  not  mean  restoring  software  to  its  former 
state,  rather  it  involves  changes  away  from  the  previous 
implementation.  In  the  case  of  hardware,  the  former  oper¬ 
ating  condition  was  the  ideal  and  deterioration  has  caused 
degraded  performance.  Restoration  of  hardware  to  the  former 
operating  condition  will  restore  optimum  performance.  With 
software,  however,  defects  or  deficiencies  in  the  former 
state  will  have  caused  degraded  performance,  and  software 
must  be  changed  to  a  state  different  from  the  original  in 
order  to  restore  optimum  performance.  Software  maintenance 
becomes  a  process  in  which  the  software  is  continually 
changed  in  order  that  its  performance  may  be  improved  or 
maintained.  Unf or tunately,  software  maintenance  is  often  so 
poorly  done  that  the  software's  performance  is  neither  main¬ 
tained  or  improved.  The  nature  of  software  maintenance  is 
well-summarized  below: 
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Unfortunately,  the  nature  of  hardware  and  software 
errors  differ  in  at  least  one  fundamental  character¬ 
istic  -  hardware  deteriorates  because  of  a  lack  of  main¬ 
tenance,  whereas  software  deteriorates  because  of  the 
presence  of  maintenance  [Ref.  7:  p.  11]. 

A  landmark  study  cf  software  maintenance  is  that  done  by 
Bennet  P.  Lientz  and  E.  Burton  Swanson  [Ref.  2].  In  it  the 
authors  specified  three  basic  categories  of  software  mainte¬ 
nance  : 

1.  Corrective  maintenance:  Emergency  program  fixes  and 

routine  debugging. 

2.  Adaptive:  The  accommodation  of  changes  to  data 

inputs  and  fields,  and  to  hardware  and  software. 

3.  Perfective  maintenance:  Enhancements  for  users, 

improvements  cf  program  documentation,  and  recoding 
for  efficiency  in  computation.  [Ref.  2:  p.  68]. 

A  1982  study  by  Rome  Air  Development  Center  (RA  DC)  grouped 
software  maintenance  into  four  basic  categories  [Ref.  6]. 
While  very  similar  to  the  categories  of  [Ref.  2],  the  RADC 
study  included  a  category  of  "modifying"  maintenance. 

4.  Modifying:  Reguirements  or  specifications  are 
changed.  These  changes  may  result  from  inadequate 
initial  analysis  and  specifications;  they  may  spring 
from  new  insights  or  better  ideas  about  the  reguire¬ 
ments  and  specifications,  or  they  may  be  caused  by 
evolving  applications  and  environments. 

A  General  Accounting  Office  (GAO)  study  [Ref.  8:  pp. 
28-29]  offered  six  categories  of  software  maintenance: 

1.  Modify  or  enhance  the  software  to  make  it  do  things 
for  the  end  user  that  were  not  requested  in  the  orig¬ 
inal  system  design. 

2.  Modify  or  enhance  software  to  make  it  do  things  for 
the  end  users  that  were  called  for  in  the  original 
design  but  which  were  not  present  in  the  first 
production  version  of  the  software. 
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3. 


3.  Remove  defects 

in  which 

the  software 

does  something 

other  than  what 

the  user 

wanted. 

4.  Remove  defects 

in  which 

the  software 

is  programmed 

incorrectly. 

5.  Optimize  the  software  to  reduce  the  machine  cost  of 
running  it,  leaving  the  user  results  unchanged. 

6.  Make  miscellaneous  modifications,  such  as  those 
needed  to  interface  with  new  releases  of  operating 
systems. 

The  various  categories  of  software  maintenance  may  be 
abstracted  into  two  broad  categories: 

•  Corrective:  Corrective  maintenance  may  be  character¬ 
ized  as  modifications  that  leave  the  functional  spec¬ 
ifications  of  the  system  unchanged.  Such  maintenance 
is  necessary  and  mandatory,  in  the  sense  that  the 
system  cannot  operate  or  existing  specifications 
cannot  be  met.  This  would  include  corrective  and 
adaptive  maintenance  categories  of  Lientz  and  Swanson 
and  RADC,  and  categories  3  through  6  from  the  GAO 
study. 

•  Enhancement:  Enhancement  maintenance  changes  the 

original  functional  specifications  of  the  system  tut 
leaves  the  primary  functions  intact.  That  is  to 
say,  an  enhancement  may  add  a  report  that  was  not 
called  for  in  the  original  specifications  but  which 
is  now  required  by  a  user  due  to  changed  government 
reporting  regulations,  but  an  enhancement  does  not 
change  a  payroll  system  to  comprehensive  management 
system  integrating  payroll,  accounting  and  inventory 
functions.  Two  maintenance  activities  not  specifi¬ 
cally  included  in  previous  categories  are  maintenance 
due  to  a  growth  in  the  system  or  as  a  response  to 
changing  requirements.  Growth  of  a  system  includes 


expansion  or  the  number  ox  users  serviced  or  files 
generated  and  accessed.  Changing  requirements  are 
represented  ty  the  changed  government  regulations 
example,  such  as  the  proposed  nine-digit  Zip  Code 
change.  Enhancement  maintenance  is  considered 
largely  discretionary.  This  would  include  Perfective 
maintenance  category  of  Lientz  and  Swanson,  perfec¬ 
tive  and  modifying  categories  of  RADC,  and  categories 
1  and  2  from  the  GAO  study. 


B.  SOFTWARE  HAIHTENA8CE  ACTIVITIES 

A  popular  misconception  about  software  maintenance,  one 
reinforced  ty  the  use  of  the  term  "maintenance",  is  that  the 
primary  activity  is  the  correction  of  "bugs".  The  three 
studies  discussed  earlier  revealed  that  correcting  tugs  is  a 
small  part  of  the  actual  maintenance  effort.  Figure  2. 1 
shows  the  distribution  of  software  maintenance  activities  in 
the  organizations  studied  in  [Ref.  2],  while  Table  I 
compares  corrective  and  enhancement  maintenance  percentages 
for  each  of  the  three  studies  cited. 

Successful  software  maintenance  depends  upon  gaining  a 
level  cf  understanding  of  the  software  system.  Software 
cannot  be  maintained  unless  those  responsible  for  mainte¬ 
nance  understand  the  software.  Maintenance  personnel  spend 
at  least  half  of  their  time  trying  to  understand  -  the 
system  code,  the  system  documentation,  and  the  requests  from 
the  users.  Figure  2.1  shows  data  on  the  activities  cf  main¬ 
tenance  personnel  in  performing  an  enhancement.  Maintenance 
personnel  spend  about  47$  of  their  time  studying  when  making 
an  enhancement,  and  about  62$  when  making  a  correction 
[Ref.  9:  p.  2].  In  a  study  of  application  program  mainte¬ 
nance  it  was  observed  that: 


Figure  2.  1 


Software  Maintenance  Activities. 


Under  standing  the  intent  and  style  of  i mpleae nta tion  or 
the  original  programmer  was  the  major  cause  of  time  and 
difficulty  in  maRing  the  change  [  Rer.  10:  p.  8], 


C.  A  DEFINITION  OF  SOFTWARE  MAINTENANCE 

The  authors'  research  has  yielded  numerous  definition 
cf  software  maintenance  that  encompass  some  or  all  of  ti. 
above  named  categories.  The  definitions  iiri<_-c  in  tn 
manner  m  which  they  treat  the  abstracted  categories  o 


TABLE  I 

Corrective  vs.  Enhancement  Maintenance 

Corrective  Enhancement 


Lientz  S 

Swanson 

17 

64 

GAC 

19 

51 

R  A  EC 

3  1 

61 

note : 

Corrective  maintenance  figures 

do 

adaptive 

mamtena  nee 

[Kef.  9:  p.  1,  6:  p*  27] 


"corrective  maintenance"  and  "enhancement  maintenance".  A 
definition  of  software  maintenance  that  includes  both 
corrective  and  enhancement  categories  is  termed  an  "inclu¬ 
sive"  definition.  A  definition  that  includes  corrective  tut 
not  enhancement  is  an  "exclusive"  definition.  Enhancement 
maintenance  in  this  context  is  termed  "continued  develop¬ 
ment",  or  perhaps  "production  programming". 

Software  maintenance,  for  the  purposes  of  this  thesis, 
will  he  defined  as: 

....all  those  activities  associated  with  a  software 
system  after  the  system  has  been  initially  defined, 
developed,  deployed  and  accepted  [Ref.  6:  p.  9]. 


This  may  be  summarized  as  the  "function  of  keeping  software 
in  an  operational  mode"  [Ref.  11:  p.  139].  This  inclusive 
definition  is  used  because: 


1.  Ecth  corrective  and  enhancement  maintenance  arc 
rerformed  by  the  same  organization,  and  often  by  the 
same  person.  Approximately  two-thirds  of  the  systems 
studied  in  [Ref.  2]  were  maintained  by  one  or  two 
people.  3oth  forms  of  software  maintenance  are 
performed  concurrently  in  the  same  environment  using 
the  same  tools. 

2.  The  bulk  of  the  effort  in  software  maintenance  is  in 
understanding  the  software. 

3.  The  term  "maintenance"  has  oeen  accepted  as  referring 
tc  both  correction  and  enhancement,  despite  the  poor 
ccnnotation  of  the  word. 

4.  The  inclusive  definition  reflects  the  concept  of 
software  evolution.  With  the  inclusive  definition 
software  may  gradually  evolve  from  the  original 
product,  rather  than  being  continually  redefined  and 
redeveloped. 

5.  It  is  difficult  to  say  where  the  separation  between 
corrective  maintenance  and  continued  development 
would  occur.  Given  that  both  activities  are  usually 
performed  by  the  same  person,  such  a  distinction 
becomes  meaningless. 

D.  SOFTWARE  MAINTENANCE  AND  THE  SOFTWARE  LIFE  CICLE 

The  software  life  cycle  is  the  multiphase  process  begin¬ 
ning  with  problem  definition  and  continuing  to  software 
system  obsolescence.  The  software  life  cycle  is  separated 
into  two  primary  phases,  the  development  phase  and  the  main¬ 
tenance  phase.  While  there  is  some  debate  over  the  validity 
of  this  separation  given  the  evolving,  continually  devel¬ 
oping  nature  of  software  systems,  it  will  be  adhered  to  in 
th*s  thesis  because  it  supports  tne  accepted  inclusive  defi¬ 
nition  of  software  maintenance.  The  sub-phases  of  the 
development  phase  are: 


22 


I 


I 


t 


s 

i 


4 


I 


« 


4 


4 


1.  Requirements  analysis:  The  object 

is  to  define  the  requirements  of  a 
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•  Testability:  The  ease  with  which 

changes  may  be  demonstrated. 

•  Modifiability:  The  ease  with  which 
be  modified.  [Ref.  11:  pp.  36-37  ], 

The  maintenance  phase  is  very  similar 
phase  with  the  exception  of  the  i 
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under  standing  the  software.  Figure  2.2  shows  the  mainte¬ 
nance  life  cycle.  All  aspects  of  the  modification  approach 
must  be  considered  in  the  context  of  the  existing  installed 
software,  not  just  in  ter  is  of  the  structural,  human  engi¬ 
neering,  reliability,  a r.  1  efficiency  factors  that  are  the 
major  considerations  when  developing  software.  The  mainte¬ 
nance  objective  is  to  limit  tr.e  effect  of  a  modification  on 
ether  parts  of  the  installed  software  and  on  user  inter¬ 
faces,  to  avoid  excessive  confusion  and  retraining  as  well 
as  tc  avoid  compromising  system  integrity  and  guality.  Once 
an  understanding  of  the  software  is  gained,  the  maintenance 
phase,  particularly  in  tae  case  of  enhancement  maintenance, 
proceeds  as  a  microcosm  of  the  development  phase. 

The  stages  of  the  software  maintenance  phase  may  be 
defined  as  follows: 

1.  Understand  the  Software:  During  this  stage  the  soft¬ 
ware  system  pregram  listings  and  available  documenta¬ 
tion  are  studied  in  order  to  gain  an  understanding  of 
the  system’s  logic  and  processes.  The  user’s 
complaint  of  error  or  reguest  for  modification  is 
also  studied  in  order  to  determine  what  action  needs 
tc  be  taken. 

2.  Define  Objective  and  Approach:  This  stage  includes: 

a)  Requirements  Analysis:  The  system  capabilities  and 
the  resources  needed  to  provide  the  modification 
are  defined  in  the  context  of  existing  system 
capabilities  and  constraints. 

b)  Specification:  Each  new  function  to  be  performed 

by  the  software  modification  and  the  impact  on 
existing  functions  is  precisely  defined. 

c)  Design:  Changes  to  the  design  algorithms  and 

procedures  are  defined,  or,  in  the  case  of  poor 
documentation,  new  algorithms  are  developed  to 
describe  hew  each  new  or  modified  function  is  to 
be  performed. 


d)  Check-point  review:  This  step  affords  a  chance  to 
validate  and  verify  the  proposed  nodif ication. 
The  software  manager  must  evaluate  whether  the 
proposed  mcdif ication  accurately  and  completely 
addresses  the  problem,  and  whether  the  cost  and 
impact  of  the  nodif  ication  justifies  implementa¬ 
tion  . 

3.  Implement  the  Modification:  This  is  the  ceding 

stage,  where  the  modification  design  is  correctly 
translated  into  well- st ructured  code. 

4.  Revalidating  the  Software:  During  this  stage  it  must 
be  demonstrated  that  the  modifications  ace  correctly 
implemented,  that  the  software  system  as  a  whole 
still  functions  correctly,  and  tnat  software  auality 
has  not  been  harmed  by  the  modification.  The  actual 
testing  of  the  software  modification  an  3  its  impact 
on  the  system  follows  from  the  testing  steps  of  the 
design  process: 

a)  Unit  testing:  Each  module  changed  is  unit  tested 

to  determine  if  it  functions  properly. 

b)  Integration  Test:  Regression  testing  is  performed 
as  each  module  is  re-integrated  into  the  system  to 
determine  if  any  other  parts  of  the  system  have 
teen  adversely  affected  by  the  modification. 

c)  System  and  acceptance  Test:  The  changed  system  is 
tested  to  ensure  that  it  meets  both  the  original 
design  and  the  modification  specif ications. 

The  goal  of  minimizing  the  impact  of  a  modification  on  a 
software  system  is  both  complex  and  difficult  to  achieve. 
This  is  primarily  due  to  the  'ripple  effect'  ;  the  side 
effect  of  modifying  software  such  that  changes  to  one  part 
of  a  software  system  affect  other  areas  of  the  system 
[Ref.  11:  p.  154].  The  ripple  effect  is  due  to  the  various 
interrelationships  between  modules  in  a  program  and  between 


programs  in  a  software  system.  Modules  and  programs  may  be 
related  in  the  terms  of  functions  or  variables  they  share. 
Any  change  to  a  module  has  the  potential  to  propagate  its 
effect  throughout  the  code.  Changes  to  correct  errors  show 
at  least  a  20  -  50’S  chance  of  generating  further  errors 
[Ref.  12:  p.122]. 

The  effort  and  the  difficulty  of  implementing  the  change 
is  net  simply  a  matter  of  rewriting  the  necessary  'code  to 
implement  the  change,  but  must  also  include  an  examination 
cf  ether  parts  of  the  system  to  determine  if  alditior.al 
adjustments  to  compensate  for  the  change  must  be  made. 
Usually  this  involves  a  manual  search  of  the  code  to  iden¬ 
tify  any  other  affected  modules,  a  process  that  often 
reguires  more  time  and  effort  than  rewriting  the  code. 

The  software  life  cycle  is  represented  graphically  in 
terms  of  resource  (usually  manpower)  use  over  time.  There 
are  several  views  as  to  how  such  a  representation  should 
look.  Cne  view,  that  of  Putnam  and  others  £  Ref .  13],  holds 
that  the  life  cycle  closely  resembles  a  Rayleigh  curve  with 
the  inflection  point  representing  the  delivery  of  the  soft¬ 
ware  system  to  the  user  and  the  start  of  the  maintenance 
phase  (figure  2.3).  The  bulk  of  the  effort  occurs  in  the 
maintecance  phase.  The  effort  reguired  to  maintain  a 
system  steadily  decreases  over  time  [Ref.  13:  p.  12]. 
Enhancements  that  exceed  the  level  of  effort  should  be 
treated  as  new  development. 

An  alternative  view  holds  that  the  effort  varies  over 
time  as  each  new  enhancement  reguest  initiates  a  mini- 
development  cycle  (Figure  2.4).  Ail  enhancements,  regard¬ 
less  of  scope,  are  treated  as  continuation  of  the  original 
system  instead  of  new  developments.  This  view  supports  the 
software  evolution  perspective  taken  in  this  thesis,  and 
seems  to  tetter  represent  the  industry  and  government  policy 
of  issuing  successive  "releases"  (major  changes  or  revi¬ 
sions)  of  a  software  system. 
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Figure  2-3  Software  Life  Cycle  -  Putnam. 


Ideally,  given  a  stable  maintenance  environment  working 
on  a  well-documented,  well-designed  system  using  maintenance 
techniques  incorporating  sta te- or- the- ar t  technology,  the 
curve  in  Figure  2.4  will  gradually  decrease.  Each  'hump' 
will  be  lower  than  its  predecesser  as  the  system  is  gradu¬ 
ally  refined  and  the  ripple  effects  are  tightly  controlled. 
Unfortunately,  the  reality  is  more  accurately  represented  in 
Figure  2.5,  where  the  resources  required  to  support  the 
system  increase  steadily  over  time.  Enhancements  are 
requested  that  exceed  the  capacity  of  the  system  tc  evolve. 
Poor  design  practices,  poor  documentation  and  poor  mainte¬ 
nance  practices  fuel  the  ripple  effect  and  errors  propagate 
through  the  system.  Any  oscillation  erfe-ct  due  to  enhance¬ 
ment  is  dampened  out  in  t he  continual  Lattle  against  bugs. 


MAINTENANCE  PHASE 


Time 

[Ref.  11:  p.  122] 


Figure  2.4  Software  Life  Cycle  -  HcClure. 

E.  LASS  OF  PROGRAM  ITJOLOTION  AND  MAINTENANCE 

Studies  by  Belady,  Lehman  and  others  have  shewn  that 
there  exists  a  deterministic,  measurable  regularity  in  the 
life  cycle  of  a  software  system.  This  regularity  has  teen 
expressed  in  the  five  laws  of  large  program  evolution 
dynamics.  These  laws  have  been  supplemented  ty  Earty 
Eoehm’s  three  laws  cf  software  maintenance.  These  laws 

accurately  represent  observed  phenomena  in  software  evolu¬ 
tion,  and  are  useful  to  the  software  manager  in  under¬ 
standing  how  and  why  software  evolves. 

1.  Law  of  Continuing  Change:  A  system  that  is  used 

undergoes  continuing  change  until  it  is  judged  mote 
cost  effective  to  replace  the  system  with  a 
re-developed  version. 

2.  Law  of  Increasing  Entropy:  The  entropy  of  a  system 

(its  unstruc  tured  ness)  increases  with  time  unless 
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Figure  2.5  Software  Life  Cycle  -  Reality. 

specific  effort  is  made  to  maintain  or  reduce  it 
[Ref.  4:  p.  2-3]. 

Fundamental  Law  of  Program  Evolution:  Program  evolu¬ 
tion  is  subject  to  dynamics  which  make  the  program¬ 
ming  process  self-regulating,  with  statistically 
determinable  trends  and  invariances,  while  ai  fearing 
tc  be  stochastic  locally  in  time  and  space. 

Law  of  Invariant  Pork  Fate:  The  overall  level  of 
effort  in  a  large  programming  project  is  statisti¬ 
cally  invariant,  or  tends  to  remain  fairly  constant 
over  time. 

Law  of  Conservation  of  Familiarity:  For  reliable, 
planned  evolution,  a  large- program  undergoing  change 
must  be  released  at  regular  intervals  determined  by  a 
safe  maximum  release  content.  If  the  interval 
spacinj  or  maximum  content  limitations  are  exceeded. 


integration,  quality  and  usage  problems  will  occur 
with  the  resultant  time  and  cost  over-runs  [Ref.  15: 
p.  142  ]. 

Seme  additional  laws  of  software  maintenance  were 
presented  by  Barry  Boehm  in  [Ref.  16]. 

1.  law  of  Organizational  Reflection  (Conway's  Law): 
Software  products  and  the  organizations  they  serve 
grow  to  reflect  each  other. 

2.  Law  of  Glacial  Technology  Transfer:  Software  prod¬ 

ucts  are  rarely  modified  to  accommodate  a  different 
technology. 

3.  law  of  Maintenance  Leverage:  Organizational  analysis 
and  software  design  have  more  maintenance  leverage 
than  any  development  or  maintenance  actions. 


III.  FOECASTING  MAINTENANCE 


While  software  maintenance  follows  a  cyclic  pattern  of 
progressive  enhancements,  it  is  generally  performed  as  a 
level  of  effort  activity  [Ref.  1:  pp.  545].  The  cycles  of 
enhancements  and  the  difficulty  of  each  enhancement  are 
largely  unpredictable  very  far  into  the  future.  The  central 
problem  cf  forecasting  software  costs  is  predicting  what  the 
level  of  effort  will  be  over  the  operational  life  of  the 
software  system. 

Two  primary  factors  influence  the  level  of  effort  esti¬ 
mate.  The  first  is  the  amount  of  software  maintenance 
needed.  Future  software  maintenance  needs  are  driven  by 
error  repair  and  changes  rising  from  external  factors. 
Cperational  systems  fulfilling  current  and  projected  mission 
needs  will  naturally  require  maintenance  for  seme  time  into 
the  future,  and  may  require  considerable  staff  to  support 
new  releases  and  revisions.  The  second  factor  is  the 
perceived  benefit  of  the  software  to  the  organization,  which 
depends  upon  the  worth  of  the  software  relative  to  other 
resource  requirements.  The  two  forces  combine  to  yield  a 
level  of  effort  sufficient  to  correct  software  errors  and 
make  most  changes  due  to  external  factors  within  a  reason¬ 
able  time.  It  is  net  completely  clear,  however,  how  the 
amount  of  maintenance  needed  and  its  perceived  benefit 
interact  to  determine  a  level  of  effort  [Ref.  17:  pp.  4]. 

The  estimating  problem  is  complicated  by  the  unpredic¬ 
table  nature  of  maintenance  ripple  effects.  Hopefully, 
analysis  of  available  documentation  and  careful  regression 
testing  will  help  tc  eliminate  errors,  but  the  software 
manager  must  recognize  this  complication  to  his  estimation 
problem.  While  none  of  the  published  techniques  or  models 


available  to  the  authors  specifically  addressed  the  ripple 
effect  in  the  estimating  process,  a  realization  of  the 
phenomenon  is  often  imbedded  in  the  representation  of  main¬ 
tenance  personnel  shill  levels.  Intuitively,  the  more 
experienced  analysts  and  programmers  are  more  likely  to 
detect  potential  ripple  effects. 

Cnee  the  level  of  effort  has  been  determined,  software 
maintenance  labor  costs  are  relatively  easy  to  estimate 
using  the  appropriate  labor  rates.  Software  maintenance  is 
a  labor-intensive  activity,  and  labor  costs  are  dominant. 
Costs  associated  with  computer  hardware  and  support  software 
may  be  included,  but  such  costs  are  normally  attributed  to 
activity  overhead  as  those  elements  benefit  other  activities 
in  addition  to  the  maintenance  of  a  particular  software 
system.  A  software  manager  should  be  aware  of  the  benefits 
of  acquiring  sophisticated  support  software  to  replace  main¬ 
tenance  personne  1  [Hef-  18:  p.  247]. 

The  future  need  for  software  maintenance  and  its 
perceived  benefit  are  difficult  to  quantify.  Thus  the  soft¬ 
ware  manager  requires  methods  somewhat  more  quantifiable  and 
sustainable  to  generate  reasonable  estimates  of-  software 
maintenance  costs.  The  following  chapters  will  discuss  such 
methods  and  how  a  software  manager  should  approach  the  task 
of  estimating  the  software  maintenance  level  of  effort. 

The  foundation  of  any  approach  to  forecasting  software 
maintenance  is  the  estimator's  own  experience  and  judgement, 
the  blend  of  which  will  hereafter  be  referred  to  as  "experi¬ 
enced  judgement".  The  software  manager  must  apply  his  or 
her  own  experienced  judgement  to  the  f orecasting/estimating 
methodology.  Experienced  judgement  is  either  applied 
directly,  as  in  direct  estimating  or  estimating  by  analogy, 
or  it  is  used  to  directly  estimate  the  parameters  upon  which 
a  parametric  model  is  based.  Published  cost  estimating 
models  reduce  the  amount  of  judgement  needed  by  providing 


table  of  values  for  all  parameters  used,  and  the  role  cf  the 
estimator  is  reduced  to  one  of  picking  numbers  and  plugging 
them  into  formulas.  One  must  remember  that  these  models 
were  derived  from  the  model  designer's  experience,  modified 
by  statistical  analysis  of  sample  populations,  and  will  not 
apply  to  all  environments.  The  software  manager  must  under¬ 
stand  and  appreciate  the  char acteristics  and  limitations  of 
any  approach  used  tc  forecast  future  software  maintenance 
needs.  Any  approach  the  estimator  cares  to  use  will  yield 
an  estimate.  The  accuracy  of  that  estimate  depends  upon  the 
estimator's  understanding  of  the  software  being  maintained, 
the  environment  within  which  it  will  be  maintained,  and  the 
applicability  of  the  cost  estimation  approach  to  the  soft¬ 
ware  and  the  environment.  The  estimator  must  ask  the 
following  guestion:  "Coes  this  approach  fit  my  situation  and 


IV.  DATA  RENOIR  EE  FOR  MAINTENANCE  COST  ESTIMATION 


The  basic  manage  lent  tenet:  "You  can’t  manage  what  you 

can't  measure"  applies  to  the  management  of  software  mair.te- 
E  nance  with  the  caveat  "You  can't  measure  what  you  don't  keep 

data  cn."  Accurate  and  complete  data  collection  is  the 
heart  of  any  algorithmic  technique  to  estimate  software 
maintenance  costs.  Without  good  data,  the  parametric  values 
{  of  the  model  cannot  he  reliably  derived  and  the  model  cannot 

be  accurately  calibrated  to  the  maintenance  activity 
environment. 

The  guestion  is  then  raised  "What  data  must  be 
collected?"  The  data  required  falls  into  two  broad  catego¬ 
ries: 

•  Characteristics  of  the  Software 

^  •  Characteristics  of  the  Maintenance  Environment. 

The  characteristics  presented  in  Table  II  and  below  are 
derived  from  published  analysis  of  software  cost  estimation 
models  [Ref.  19,  20],  and  the  authors'  own  analysis  of 

[jl  available  models  [Ref.  1,  13,  21,  22],  The  listing  is  not 

all  inclusive:  the  immaturity  of  software  maintenance  cost 
estimation  is  such  that  an  attempt  at  presenting  a  compre¬ 
hensive  list  of  all  variables  that  influence  software  main¬ 
tenance  would  be  presumptuous.  It  is  intended  more  as  a 
reference  to  the  software  manager  in  the  hope  that  he  or  she 
may  be  guided  toward  a  better  understanding  of  the  scope  and 
nature  of  the  task. 


TABLE  II 

Software  Cost  Data  Elements 


Software  Characteristics  Environment  Characteristics 


Development 
manpower 
total  eff 


History 

(MM/yr) 

ort 


total  time 


environmental  descri 


P 


Maintenance  Historv 
valid  errors  found 
enhancements  started 
enhancements  deferred 
emergency  fixes  started 
original  LOC 
modified  LOC 
new  LOC 

original  modules 
modified  modules 
new  modules 
total  modules 


Personnel 

experience 

language  familiarity 
support  S/W  familiarity 
application  familiarity 
participation  in  design 
personnel  continuity 
real  productivity 

Computer  attributes 
size  and  aqe 
memory  constraints 
machine  constraints 
operating  system 
access  of  maintenance 
personnel  to  computer 
scheduling  priorities 


Tvpe  of  Program 
application 
language  used 
structure 


Software  Tools 
software  tools 
available  to 
maintenance  personnel 


Complexity 

size 

operators 

operands 

degree  of  unigueness 
algorithm  complexity 
H/w  -  s/w  interfaces 
input  -  output  files 
module  complexity 


Programming  Techniques 
Extent  to  which 

modern  pr  gramming 
practices  are  used 

Data  Base 
size 

avaiiabilitv  to 
main!  personnel 


Doc  umentation 
tcp- level 
deta il 
currency 


LCC  -  lines  of  code 
H/W  -  hardware 
S/W  -  software 
MM  -  man-months 
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A.  SCFTKAFE  CHARACTERISTICS 


1 .  Cevelo pmen t  history 

Manpower  during  development  (Mfl/yr)  :  The  man-months  (H.Vyr) 
per  year  of  the  the  development  phase,  broken  down  by  phase 
of  the  lifecycle  (e.g..  Requirements  Analysis, 
Specification,  Design,  Coding,  Testing)  and  by  labor  mix 
(e.g.,  programmers,  analysts  ,  documentation  specialists, 
etc. )  . 

Total  development  effort:  The  total  number  of  man-months 

expended  during  development. 

Development  time:  Calendar  months  of  development. 

Description  of  development  environment:  A  description  of 

the  development  environment  to  include 

•  computer  used 

•  tools  and  automated  programming  aids  used 

•  languages  used 

•  software  engineering  techniques  and  modern  program¬ 
ming  practices  used. 

It  should  be  noted  which  of  the  above  were  new  to  the  devel¬ 
opment  environment. 

2 •  Maintenance  History 

No.  of  valid  errors  found  per  month:  Valid  errors  found 

sir.ce  program  acceptance 

No.  of  enhancements  started  per  month:  Number  of  user  or 

environment  driven  enhancements  started  since  program 
acceptance. 
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Enhancements 


L 


No.  of  enhancenents  deferred  per  month: 
deferred  for  what-ever  reason  since  program  acceptance. 

No.  of  emergency  fixes  started  per  month:  Emergency  fixes 

since  program  acceptance. 

Original  lines  of  code:  Lines  of  code  in  program  at  accept¬ 
ance  . 

Modified  lines  of  cede;  Lines  of  code  modified  since 
acceptance. 

Hew  ICC:  Lines  of  cede  added  since  acceptance. 

Total  IOC:  Cumulative  lines  of  code. 

Original  modules:  Modules  in  program  at  acceptance. 

Modified  modules:  Modules  modified  since  acceptance 
New  modules:  Modules  added  since  acceptance. 

Total  modules:  Cumulative  modules  in  program. 

3 •  Type  of  Program 

Function:  Scientific,  transaction  processing,  real  time 

control  system,  operating  system,  etc.  The  logical  function 
has  a  significant  impact  on  the  complexity  of  the  program. 

language  used:  High  order  language  (HOL)  --COEOL 
FORTRAN,  P11 ,  etc. 

Assemhly  language 


Uniqueness  of  language--is  it  common  and 
well-known  like  FORTRAN  or  a  specific, 
obscure  assembly  language? 


Structure:  Those  attributes  that  contribute  to  the  reua- 
ability  cf  the  program  form  [Ref.  23:  p.  72].  The  hierarch¬ 
ical  representation  that  indicates  tne  relationship  between 
modules.  A  subjective  parameter  value  is  useful  here. 
"Well-structured"  could  mean  code  featuring  independent 
modules  employing  parameter- passing  and  information  aiding. 
"Poorly  structured"  could  refer  to  spaghetti  code  replete 
with  GO  TO's  . 


4 .  Co  mplexi tv 

Size:  Program  size  is  measured  in  "lines  of  code",  an 
expression  which  can  mean  many  things.  Exactly  what  consti¬ 
tutes  a  "line  of  cede"  is  difficult  to  define  because 
programs  consist  cf  more  than  executable  statements. 
Programs  may  include  comment  lines,  data  declarations,  job 
control  language  statements,  format  statements  and  macro¬ 
instructions.  A  counting  method  may  consider  every  state¬ 
ment  to  be  a  line,  whereas  other  methods  may  only  consider  a 
subset,  such  as  executable  lines  and  data  declarations. 
Barry  3oehm  uses  "delivered  source  instructions"  as  his 
vehicle,  and  defines  it  as  follows: 


This  term  includes  all  program  instructions  created  by 
project  personnel  and  processed  into  machine  code  by 
some  combination  of  preprocessors,  compilers,  and  assent 
biers.  It  excludes  comment  cards  and  unmodified  utility 
software.  It  includes  job  control  language,  format 
statements,  and  data  declarations. 


[Ref.  1:  p.  59] 

A  more  subtle  problem  occurs  when  counting  lines  of 
code  for  programs  written  in  HOL.  FORTRAN  commonly  uses  one 
statement  per  line,  although  continuation  lines  are  allowed 
and  some  FORTRAN  versions  allow  multiple  statements  per 
line.  A  freely  structured  language  like  C030L  uses  punctua- 


tion  to  delimit  statements  and  a  line  of  code  may  contain 
several  statements.  A  line  of  code  in  P11  may  be  everything 
written  between  semicolons. 

Recognition  of  the  problem  of  how  to  measures  size 
is  necessary  to  effectively  manage  resources.  Programmer 
productivity  metrics  are  meaningless  unless  the  software 
manager  understands  the  line-counting  rules  in  effect. 
These  rules  should  be  documented  and  clearly  understood  by 
alj.  who  interact  with  software  maintenance. 

Operators:  The  number  of  unique'  operators  and  the  total 
number  of  operators  in  the  program. 

Operands:  The  number  of  unigue  operands  and  the  total 
number  of  operators  in  the  program.  Operators  and  operands 
are  used  in  M.  Halstead's  Complexity  metrics  [Ref.  24]. 

Degree  of  uniqueness:  A  subjective  measure  of  the  unique¬ 
ness  of  the  function  and  the  software  system.  The  impact 
here  is  personal  familiarity  with  the  problem,  the  hardware 
and  the  software.  The  more  common  the  function,  hardware 
and  software,  the  lesser  the  degree  of  complexity  and  the 
more  likely  maintenance  personnel  will  quickly  understand 
the  system. 

Complexity  of  algorithm:  Again,  this  is  a  subjective 
measure.  A  more  complex  and  sophisticated  algorithm  (e. g. , 
electromagnetic  signal  analysis)  will  be  more  difficult  to 
understand  than  a  relatively  simple  one  (e.g.,  payroll 
calculation).  If  the  mathematical  sophistica tion  of  the 
underlying  algorithm  is  beyond  the  perspicacity  of  the 
programmers  and  analysts  available  then  there  evolves  a 
strong  inclination  not  to  touch  the  program  for  fear  it  will 
"break" . 


H/H  -  S/W  interfaces:  Types  cf  interfaces  include  data 
storage  and  retrieval  devices,  on-line  communication 
devices,  real-time  command  and  control,  and  interactive 
terminals.  The  numter  and  diversity  of  interfaces  directly 
impacts  the  complexity  of  the  system. 


Inpat-output  files  format:  The  number  of  different  formats 

the  system  reads  and  outputs,  including  card,  tape,  disk,  or 
screen  formats.  The  type  of  file  format  and  the  number  of 
files  accessed  may  impact  system  complexity  [Eef.  21  :E-2]. 
The  DoD  Micro  Estimating  Model  used  to  estimate  development 
costs  incorporates  different  file  formats  as  input  parame¬ 
ters,  but  weights  each  the  same  [Ref.  19:  p.  A-15].  This 
implies  the  impact  on  maintenance  costs  is  either  negli¬ 
gible,  cr  too  dependent  upon  specific  equipment  to  incorpo¬ 
rate  in  a  general  model. 

Complexity  of  modules:  Table  III  compares  the  subjective 

complexity  ratings  as  a  function  of  the  type  of  operation  to 
be  primarily  performed  by  the  module  [Ref.  1:  p.  391], 

While  the  ratings  are  designed  to  be  incorporated  into  Barry 
W.  Boehm’s  COCOMO  model,  they  do  assist  the  software  manager 
in  understanding  some  of  the  characteristics  of  a  program 
that  directly  impact  complexity. 

Documentation:  Documentation  is  essential  to  software  main¬ 

tenance.  Maintenance  personnel  must  be  able  to  understand 
how  and  why  a  program  operates  in  order  to  perform  software 
maintenance.  Documentation  is  the  tool  used  to  gain  that 
understanding.  While  software  documentation  is  a  controver¬ 
sial  subject,  most  software  experts  agree  on  the  following: 

1.  Well-documented  programs  are  easier  to  work  with  that 
undocumented  programs,  but  incorrect  documentation  is 
far  worse  than  none  at  all. 
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TABLE  III 
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2.  Good  documentation  implies  conciseness,  consistency 
of  style,  and  ease  of  update. 

3.  A  program  should  he  its  own  documentation:  that  is,  a 
well-documented  program  should  take  advantage  of  the 
self-docume nting  facilities  offered  by  the  language 
and  should  have  its  documentation  built  into  the 

I  source  code  to  the  maximum  extent  practicable 

[Eef.  25:  p.175]. 

Documentation  takes  many  forms.  Robert  L.  Glass  [Ref.  23: 
p.  163]  offers  two  categories  of  documentation  of  interest 
to  the  software  manager:  top-level  software  definition  and 

detail-level  software  definition.  Table  IV  describes  the 
two  categories  in  mere  detail.  Additional  categories  may 
include  user,  test  and  operation  documentation. 

Currency/correctness  of  documentation:  To  be  of  any  value, 

documentation  must  be  both  correct  and  current. 
Documentation  that  dees  not  accurately  reflect  the  current 
state  of  a  system  is  worse  than  none  at  all.  Unfortunately, 
most  system  documentation  resides  in  tomes  that  gather  dust 
on  shelves.  Maintaining  documentation  is  a  task  that 
everyone  tries  to  avoid,  yet  must  be  done  if  the  software 
system  is  to  survive.  Tools  are  available  to  aid  in  this 
task . 


E.  ENVIRONMENTAL  CHARACTERISTICS 

1 .  Personnel 

The  impact  of  personnel  character istics  on  software 
mainterance  and  the  management  of  personnel  to  accomplish 
the  software  maintenance  function  will  be  discussed  in 
Chapter  VI.  ^his  section  will  define  the  terms  used. 
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TABLE  I? 

Maintenance-Critical  Documentation 

I.  Tcp-level  software  definition  (document) 

a.  Overall  structure  summary 

b.  Overall  database  summary 

c.  Design  decision  data 

d.  Underlying  philosophy 

e. .  Midlevel  structure(s) 

f.  Midlevel  data  base  (s) 

g.  Index  to  listing 

II.  Detail  level  software  definition  (listing) 

a.  Commentary  for 

1.  Detail  structures 

2.  Detail  database 

3.  Detail  functions 

4.  Implementation  anomalies 

b.  Readable  names 

c.  Structured,  indented  code 

[ Eef .  23:  p.  163] 


Programming  experience:  The  number  of  years  of  programming 
experience  an  individual  has.  When  used  as  an  input  to 
estimate  cost  estimating  models,  it  is  assumed  that  more 
experience  has  a  positive  impact  on  reducing  costs.  This 
may  cr  may  not  be  true,  and  is  heavily  dependent  on  the 
ctber  characteristics  listed  below. 
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Familiarity  with  language:  A  subjective  measure  of  the 

expertise  an  individual  has  with  a  particular  language. 
Soire  studies  have  shewn  experience  in  a  number  of  languages 
is  of  greater  benefit  than  considerable  experience  in  cne 
lar  guage. 

Familiarity  with  hardware  and  support  software:  A  subjec¬ 

tive  measure  of  the  experience  an  individual  has  with  the 
computer  and  its  support  software  (e.g.,  operating  system, 
compilers  and  available  software  tools)  . 

Familiarity  with  function:  A  subjective  measure  of  the 

understanding  an  individual  has  of  the  software's  function. 
This  becomes  important  in  complex  functions,  particularly  so 
where  the  underlying  algorithm  is  abstruse  or  the  system  is 
poor ly- documented. 

Participation  in  design  effort:  The  degree  to  which  an 

individual  was  involved  in  the  design  and  development  stage 
of  the  software.  Such  experience  is  invaluable  in  helping 
maintenance  personnel  understand  the  software's  underlying 
logic  and  philosophy. 

Personnel  continuity:  Personnel  continuity  may  be  repre¬ 

sented  as  personnel  turnover.  A  maintenance  staff  with  low 
turnover  will  spend  less  time  on  job  communication  and 
training  and  more  on  productive  work. 

Peal  productivity:  Productivity  is  a  highly  controversial 

metric  that  is  extremely  difficult  to  define.  A  typical 
productivity  definition  of  "lines  of  code  written  per  man- 
month"  fails  on  four  counts. 

1.  The  definition  of  "lines  or  code"  is  imprecise,  and  a 
productivity  measure  incorporating  it  suffers  from 
sensitivity  to  line  counting  variations. 
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2. 


" Kan-month"  is  a  measure  of  effort,  not  of  produc¬ 
tivity.  While  there  is  a  correlation  between  effort 
and  productivity,  it  can  be  represented  using  the 
metric  " ma n- month"  only  with  the  greatest  caution 
[fief.  12:  p.  16]. 

3.  Ceding  is  but  a  small  part  of  tne  maintenance  effort. 
The  critical  area  of  maintenance  lies  ir.  under¬ 
standing  the  program  and  what  must  be  changed.  There 
exists  no  acceptable  metric  for  measuring  the  rate  at 
which  a  human  may  understand  a  complex  problem. 

4.  There  exists  a  tendency  to  penalize  HOL  program  in 
favor  of  assembly  language  programs  when  using  a 
"lines  of  code"  metric.  Assembly  languages  reguire 
more  lines  of  code  to  implement  a  given  function  than 
HCL,  thus  more  lines  of  assembly  code  can  be  produced 
by  a  programmer  during  the  coding  portion  of  mainte¬ 
nance  [Ref.  26:  p.  41]. 

A  more  useful  definition  of  programmer  productivity 
may  be  in  terms  of  programming  functions  per  unit  of  time 

[Ref.  27:  p.34]. 

2 .  Computer  Attributes 

Size  and  age:  Physical  attributes  of  the  host  computer  that 
affect  software  maintenance  include  the  size  (eg.  mairframe 
or  mini) ,  the  age,  memory  constraints,  machine  constraints, 
and  the  operating  system  it  will  support.  A  large  computer 
will  support  more  sophisticated  software  tools  than  a 
smaller  computer  of  the  same  age  [Ref.  1:  p.  460  ],  and  a  new 
mini  may  have  more  capability  than  an  older  mainframe.  The 
age  of  a  computer  is  critical  in  terms  of  vendor  support 
(enthusiasm  to  support  a  given  architecture  declines  with 
time),  processing  capacity,  memory  and  software 

sophis  tica  tion . 


Memory  constraints:  limitations  are  imposed  or.  the  perform¬ 
ance  of  software  maintenance  by  the  size  of  the  available 
memory.  A  machine  whose  production  work  consumes  90  **  of  its 
memory  leaves  little  to  dedicate  to  enhancement  maintenance. 

Machine  constraints:  Machine  constraints  are  the  character¬ 
istics  of  a  particular  computer  that  may  adversely  impact 
software  maintenance.  These  may  include  such  characteris¬ 
tics  as  unique  architecture,  high  operating  costs  or  a 
machine-specif ic  language  version.  Such  constraints  vary 
from  activity  to  activity,  but  it  is  sufficient  to  say  that 
a  software  manager  should  be  aware  of  the  limitations  of  the 
host  computer. 

Operating  system:  A  sophisticated  operating  system  enhances 
the  productivity  of  maintenance  personnel  by  allowing  inter¬ 
active  testing  and  debugging.  Turnaround  time  (the  time 
between  the  entry  of  a  command  or  a  program  and  the  comput¬ 
er’s  response)  impacts  the  speed  with  which  maintenance  may 
progress.  A  sophisticated  operating  system  that  supports 
virtual  memory  and  a  wide  range  of  software  tools  is  far 
more  conducive  to  effective  maintenance  than  a  batch- 
oriented  operating  system  supporting  a  compiler. 

Access  of  maintenance  personnel  to  computer:  The  number  of 
terminals  dedicated  to  maintenance  personnel,  and  the  poli¬ 
cies  regarding  terminal  use. 

Scheduling  priorities:  The  priority  given  to  maintenance 
functions.  This  is  primarily  a  management  concern,  and 
requires  both  an  awareness  of  and  commitment  to  the  impor¬ 
tance  of  software  maintenance. 


3. 


Software  Tools 

Number  and  type  of  software  tools  that  may  be 
applied  to  software  maintenance.  Tools  are  discussed  more 
fully  in  Chapter  VII. 

4.  Programming  Techniques  and  Standards 

The  extent  to  which  modern  programming  practices 
(structured  programming,  information  hiding,  etc)  are 
applied  to  software  maintenance.  Programming  technigues  are 
also  discussed  more  fully  in  Chapter  VII.  Some  measure  of 
modern  programming  practices  used  are  common  to  the  majority 
cf  cost  estimation  models  studied. 

5 .  Data  Base 

The  implications  of  data  base  to  software  mainte¬ 
nance  are  discussed  in  Chapter  VIII. 

C.  HECCUHENDATIONS 

While  the  data  base  required  to  estimate  software  main¬ 
tenance  costs  often  exists,  the  data  are  non-homogeneous. 
There  are  no  definitive  standard  metrics;  only  a  collection 
of  interpretations.  The  definition  of  software  maintenance 
itself  may  vary  within  an  organization  itself.  A  software 
manager  who  subscribes  to  the  exclusive  definition  may  be 
replaced  by  one  who  prefers  the  inclusive  definition.  Any 
data  collected  in  the  past  would  be  of  little  value  tc  the 
current  manager.  The  definition  of  software  maintenance 
also  frequently  varies  from  activity  to  activity. 
Additionally,  the  definitions  of  "lines  of  code"  and 
"complexity"  may  vary  from  activity  to  activity.  The  data 
collected  using  interpretive  metrics  are  generally  unusable 
outside  cf  its  source  environment. 
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Tc  accurately  estimate  software  maintenance  costs, 
therefore,  it  is  necessary  to  start  with  a  standardized  set 
c£  data.  A  standardized  set  of  data  must  be  collected  using 
standard,  universal  metrics.  It  is  hoped  that  PoD  and 
industry  may  agree  upon  a  uniform  set  of  software  metrics. 

Once  a  standard  set  of  software  metrics  for  cost  estima¬ 
tion  is  derived,  data  must  be  collected,  stored  in  a 
•centralized  location,  and  applied  to  existing  cost  estima¬ 
tion  models.  The  use  of  standard  data  would  go  far  to 
improving  the  accuracy  of  current  models.  Analyses  of  the 
data  may  then  be  conducted  that  will  result  in  the  next 
generation  of  more  precise,  mere  accurate,  and  viable  soft¬ 
ware  cost  estimating  methodologies.  A  uniform  data  collec¬ 
tion  instrument  must  be  designed  that  will  enable  data 
collection  in  a  consistent  manner.  This  approach  is  manda¬ 
tory  tc  avoid  problems  arising  over  which  data  to  collect, 
when  to  collect  it,  and  how  to  maintain  the  data  in  a 
machine  readable  format  for  storage  and  analysis. 
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V.  MAINTENANCE  COST  ESTIMATION 


A.  OVERVIEW 

be  the  process  of 
particularly  apt. 
ftware  development 
o  maintenance  cost 
and  Swanson  study 
aintenance  and  the 
understood.  Many 
today  to  estimate 
lable  to  estimate 
existing  develop- 
the  same  factors 
influence  mainte- 

stimating  software 
ods  and  parametric 
ily  on  the  estima- 
ienced  judgement. 
Fararaetric  models  presume  that  relationships  exist  between 
costs  and  certain  software  characteristics  [Ref.  17:  p.  9], 

E.  TRADITIONAL  METHODS 
Direct  Estimating 

Direct  Estimating  is  the  application  of  experienced 
judgement  in  its  purest  form.  The  cost  estimate  is  made 
based  on  the  individual’s  knowledge,  experience  and  judge¬ 
ment.  Current  knowledge  and  experience  relative  to  the 
particular  activity  being  estimated  is  vital  to  a  creditable 
estimate.  Excellent  judgement  is  critical  since  future 


The  use  of  the  term  "art”  to  descri 
estimating  software  maintenance  costs  is 
While  much  research  has  been  devoted  to  so 
cost  estimation,  little  has  been  devoted  t 
estimation.  Indeed,  until  the  Lientz 
[Ref.  2]  the  characteristics  of  software  m 
factors  that  influence  it  were  imperfectly 
techniques  and  parametric  models  exist 
development  costs  but  the  few  models  avai 
maintenance  costs  are  simply  extensions  of 
ment  models,  and  generally  assume  that 
influencing  development  costs  will  also 
nance  costs  [Ref.  1:  p.  536,  13:  p.  7], 

A  broad  distinction  of  approaches  to  e 
maintenance  costs  include  traditional  meth 
models.  Traditional  methods  rely  primar 
tor’s  (or  group  of  estimators’)  exper 


maintenance  activities  are  not  ax  t  to  Le  t;.e  same  as 
previous  ci.es.  Direct  estimating  say  be  corur.ti  with 
decomposition  to  yield  a  more  accurate  estimate.  The  soft¬ 
ware  system  may  be  decomposed  into  successivly  lower  func¬ 
tional  subcomponents.  3Len  a  low  enough  level  is  reached  to 
estimate  accurately,  the  estimator  applies  any  appropriate 
technique  to  estimate  each  component’s  cost.  Table  V  shows 
a  possible  subdivision  of  maintenance  into  functional 
subcomponents. 


TABLE  7 

Software  Maintenance  Functions 

Management /Super  vision 

planning,  directing,  coor¬ 
dinating  ,  and  controlling 
software  maintenance  activity 

Administration 

general  office  support 

Analysis 

studying  a  software  problem 
prior  to  taking  action 

Design 

developing  a  solution  to  a 
software  problem 

Proqramminq 

coding  and  unit  testing  cf 
software  changes 

Sistem  Testing 

formal  testing  of  a  changed 
software  testing 

Configuration  Control 

uokeep  of  master  program 
libraries,  backup  tapes, 
program  listings,  etc 

Documentation 

making  changes  to  user 
manuals,  specif icati ons, 
test  plans,  etc 

T  raininq 

train  users  on  program 
changes,  training  of  new  soft 
ware  maintenance  personnel 

[Bef.  17:  p.  9] 
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The  use  of  direct  estimating  and  decomposition  (essen¬ 


tially  hottom-up  estimating)  offers  the  advantages  of 
enhanced  estimate  quality  since  random  error  in  the  system 
estimate  will  be  reduced  by  accumulating  subcomponent  esti¬ 
mates,  and  by  enhancing  the  understanding  of  both  the  system 
and  the  maintenance  task. 

Analogy 

Analogy  is  similar  to  direct  estimating,  and  involves 
comparing  the  estimated  effort  of  performing  maintenance  on 
a  program  with  similar  historical  examples.  The  experience 
of  another  project  serves  as  a  baseline  for  the  estimate, 
which  is  then  modified  by  differences  in  project  character¬ 
istics  and  available  resources. 

Judgement  Enhancing  Techniques 

Judgement  enhancirg  techniques  are  primarily  based  on 
experienced  judgement.  The  accuracy  ox  the  estimate  is 
enhanced  through  the  use  of  methods  that  reduce  the  depen¬ 
dence  upon  one  individual's  judgements.  These  include  Group 
Consensus  or  averaging.  A  grcup  consensus  technique  may  be 
a  typical  meeting,  two  individuals  discussing  the  matter 
over  lunch,  or  the  more  formal  Delphi  technique.  The 
Wideband  Delphi  technique  [Ref.  1:  p.  335]  seeks  to  improve 
the  feedback  of  the  Delphi  technique  and  still  avoid  the 
pitfalls  of  group  dynamics  in  a  typical  meeting.  The 
process  is  time  consuming,  but 

. ...ha§  teen  highly  successful  in  combining  the  free 
discussion  advantages  of  the  group  meeting  technique  and 
the  advantages  of  anonymous  estimation  of  the  standard 
Delphi  technique  [Ref.  1:  p.  335  ]. 

A  straightforward  technique  is  to  average  several  indepen¬ 
dent  estimates.  The  independent  estimates  may  be  obtained 
using  various  estimating  methods. 


ease  of 


Traditional  methods  offer  the  software  manager 
use  and  familiarity  cf  approach.  Reasonable  estimates  of 
software  maintenance  costs  may  be  obtained  using  traditional 
methods.  However,  the  validity  of  the  estimate  rerains 
dependent  upon  the  ability  of  an  individual  (or  group)  to 
correctly  analyze  the  past  and  make  a  valid  judgement  for 
the  future.  The  analysis  of  the  past  may  oe  affected  by 
incomplete  recall,  biases,  and  inappropriate  focus  ("didn't 
see  the  forest  for  the  trees").  The  judgement  of  the  future 
may  be  influenced  by  optimism,  incomplete  understanding  cf 
the  existing  system,  or  the  pressure  of  deadlines  and 
superior s. 

C.  PARAMETRIC  MODELS 

Parametric  models  presume  that  quantifiable  relation¬ 
ships  exist  between  software  maintenance  costs  and  certain 
software  characteristics  [Ref.  17:  p.  9],  Such  relation¬ 
ships  are  usually  quantified  by  statistical  analysis  of 
historical  software  cost  data.  Once  quantified,  the  rela¬ 
tionships  become  variables  that  serve  as  major  cost  drivers 
in  mathematical  models. 

Farametric  models  may  take  either  a  macro  or  a  micro- 
level  approach,  or  employ  a  combination  of  both.  In  a 
micro-level  approach,  the  model  addresses  the  individual 
components  of  a  system.  This  approach  offers  the  advantages 
of  decomposition:  reducing  the  system  to  components  for 
which  the  level  of  effort  may  be  easily  estimated,  and 
enhancing  the  software  manager's  understanding  of  the 
system.  A  macro-level  approach  focuses  instead  on  the 

overall  system  and  its  interaction  with  the  environment.  A 
macro-level  model  is  more  apt  to  deal  adequately  wit)  the 
effects  cf  external  factors,  while  a  micro-level  approach  is 
likely  to  be  more  effective  in  estimating  potential 
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maintenance  ripple  effects.  Parametric  models  have  been 
categorized  in  a  number  of  ways  by  different  studies 
[Hef.  1:  pp.  329,  19:  p.  4-11,  17:  pp.  7-12].  The  authors 
feel  that  categories  based  upon  how  the  model  itself  was 
derived  are  of  more  value  that  ones  based  upon  the  charac¬ 
teristics  of  the  model.  Such  a  distinction  should  aid  a 
software  manager  in  deciding  the  applicability  of  a  model  to 
his  or  her  own  environment.  Eobert  Tnibodeau  [ Bef .  19:  p. 
4-11]  presents  the  following  categories: 

Begression:  A  class  of  model  structures  whose  design  is 
based  on  the  selection  of  the  life  cycle  element  of  interest 
{e.g.,  life  cycle  effort,  development  effort,  or  ceding 
effort)  and  a  hypothesized  relationship  between  the  element 
and  a  number  of  selected  inputs.  The  parameters  of  the 
hypothesized  relationship  are  obtained  by  regression  and  the 
model  becomes  a  single  cost  estimating  relationship. 

Heuristic:  This  model  structure  combines  observation 
and  interpretation  with  supposition.  It  is  the  formal 
representation  of  the  subjective  process  of  applying  experi¬ 
ence.  Relationships  among  variables  are  stated  without 
justification  (e.g.,  cost  per  pound  decreases  with 
increasing  size,  development  effort  is  related  to  type  cf 
application) .  Then  subjective  ,  semi-empirical,  or  empir¬ 
ical  adjustments  are  made  to  the  base  estimate.  Heuristic 
models  combine  a  number  of  different  estimating  techniques. 

Phenomenological:  This  type  of  model  incorporates  a 
concept  that  is  explained  in  terms  of  a  basic  phenomenon 
that  is  not  limited  to  the  mechanics  of  software 
development. 

Parametric  models  offer  the  software  manager  several 
advantages. 

1.  They  are  objective  and  not  strongly  influenced  by 
personal  biases  or  motivation. 
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2.  They  are  repeatable,  given  the  same  input  parameters. 

3.  They  objectively  represent  historical  cost  experience 
and  are  calibrated  by  historical  data. 

4.  They  are  efficient  and  able  to  support  further  esti¬ 
mates  or  sensitivity  analysis. 

5.  They  are  easily  automated. 

6.  Finally,  they  offer  a  supportable  conclusion,  one 
more  likely  to  survive  the  scrutiny  of  budget- 
ccnscious  superiors. 

While  parametric  model  are  superior  to  traditional 
methods  in  most  respects,  they  are  not,  however,  perfect. 
Host  models  are  not  satisfactory  for  wide  range  of  applica¬ 
tions  without  considerable  adjustment.  The  disadvantages  of 
parametric  models  include: 

1.  Historical  data  used  to  derive  and  calibrate  the 
model  may  not  accuratedly  represent  the  present  or 
future.  Research  to  date  on  software  cost  estimation 
has  often  been  based  on  systems  developed  using  out¬ 
moded,  inefficient  methods. 

2.  They  are  unable  to  deal  with  exceptional  conditions. 

3.  Models  cannot  compensate  for  poor  estimates  of  para¬ 
metric  values  (garbage  in  -  garbage  out)  . 

4.  The  majority  of  models  available  are  either  not 
applicable  to  the  maintenance  problem  or  represent  it 
imperfectly  [Ref.  1:  p.  342]. 

Farametric  models  can  be  used  to  estimate  software  main¬ 
tenance  costs  with  reasonable  accuracy.  As  with  any  tool, 
the  tool  user  must  fully  understand  how  the  tool  operates 
and  hew  to  use  it  effectively.  Effective  use  of  parametric 
models  to  estimate  software  maintenance  costs  reguire  under¬ 
standing  several  key  issues. 


55 


1.  Every  model  is  dependent  upon  experienced  judgement 
for  its  parametric  values.  This  is  particularly  true 
for  subjective  factors  such  as  system  complexity  and 
experience  of  personnel.  There  is  no  realistic  way 
to  avoid  using  experienced  judgement  to  estimate 
maintenance  costs  regardless  of  the  method  selected. 

2.  The  model  must  be  calibrated  to  one's  own  environ¬ 
ment.  The  model  itself  is  normally  developed  from  a 
representative  sample,  as  in  Barry  Boehm's  CCCCMO 
[Ref.  1],  cr  from  an  observed  phenomenon  of  software 
development,  as  in  Lawrence  Putnam's  SLIM  [Ref.  13]. 
Modifications  of  certain  parameters  must  be  made  to 
"fit"  the  model  to  a  particular  environment.  These 
modifications  can  be  done  either  by  the  software 
manager  or  by  an  expert  consultant  with  experience  in 
the  model.  Either  way,  the  calibration  process  is 
almost  entirely  judgement-dependent. 

3.  The  software  manager  must  have  access  to  considerable 
historical  data  about  the  system  being  maintained  and 
the  maintenance  environment.  This  data  is  critical 
to  estimating  parametric  values  and  calibrating  the 
mod*:!.  Unfortunately,  few  software  activities  under¬ 
stand  the  importance  of  accurate  records  of  software 
maintenance,  nor  are  they  aware  of  what  characteris¬ 
tics  of  the  software  and  of  the  environment  should  be 
monitored  and  recorded  to  support  the  cost  estimation 
function.  Data  management  and  its  relation  to  soft¬ 
ware  maintenance  is  addressed  in  Chapter  VIII,  while 
a  discussion  of  the  characteristics  of  software  and 
the  environment  that  should  be  monitored  and  recorded 
was  discussed  in  Chapter  IV. 
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D. 


ESTIMATING  MAINTENANCE  COSTS 


Several  different  software  cost  estimating  models  have 
teen  developed  and  osed  by  DoD  and  industry,  witn  varying 
results.  This  thesis  will  not  evaluate  any  particular 
model.  A  summary  of  studies  done  to  evaluate  existing 

models  is  presented  in  [Ref.  28:  p.  10].  Instead,  this 
section  will  focus  on  considerations  fgr  planning  an  esti¬ 
mate,  criteria  to  subjectively  evaluate  a  software  cost 
estimating  model,  and  will  summarize  a  view  of  the  status  of 
software  cost  estimation  within  DoD. 

1 •  Planning  an  Estimate 

Developing  an  accurate  software  maintenance  cost 
estimate  requires  a  significant  amount  of  effort.  The  soft¬ 
ware  manager  should  plan  the  estimate  just  as  any  project. 
The  process  for  planning  an  estimate  developed  by  Earry 
Boehm  [Ref.  1:  pp.  310-328]  and  tailored  for  software  main¬ 
tenance  by  G.  Klemas  [Ref.  17:  pp.  30-31]  is  summarized  in 
Table  VI. 

2.  Evaluating  a  Software  Maintenance  Cost  Model 

How  can  a  software  manager  evaluate  the  applicability  of  a 
particular  model  to  his  or  her  own  environment.  3arry  W. 
Boehm  offers  the  following  criteria: 

1.  Definition:  Has  the  model  clearly  defined  the  costs 
it  is  estimating,  and  the  costs  it  is  excluding? 

2.  Fidelity:  Are  the  estimates  close  to  the  actual  costs 
expended  on  the  projects? 

3.  Objectivity:  Coes  the  model  avoid  allocating  most  of 
the  software  cost  variance  to  poorly  calibrated 
subjective  factors  (such  as  complexity)?  Is  it  diffi¬ 
cult  to  jigger  the  model  to  obtain  any  result  you 


TABLE  71 

Software  Maintenance  Cost  Estimating  Procedure 


1.  Determine  the  purpose  and  objective  of  the  esti¬ 
mate.  Identify  all  costs  that  need  to  be  included  in 
the  estimate  ana  establish  accuracy  requirements. 

2.  Prepare  the  estimate  plan,  stating  purpose, 
objectives  and  requirements  of  the  estimate. 
Determine  data  and  expertise  needed  to  make  the  esti¬ 
mate,  and  decide  upon  a  technigue.  Specify  resources 
and  time  needed  to  make  the  estimate. 

3.  Eeview  the  plan.  Verify  objective  validity  and 
resource  availability. 

4.  Gather  the  necessary  data.  This  stage  will  be 
relatively  direct  for  an  existing  system  provided 
there  is  a  current  program  maintenance  manual.  If  an 
estimate  needs  to  be  done  for  a  recently  delivered 
system,  obtain  as  much  data  as  possible  about  its 
development.  Compare  with  the  best  historical  data 
available  on  similar  systems. 

5.  Cbtain  several  independent  estimates  usinc 
various  models.  Evaluate  applicability  of  a  model  to 
estimating  situation,  and  calibrate  to  own  environ¬ 
ment.  Apply  experienced  judgement  to  independent 
estimates  and  derive  an  estimate  that  optimally  satis¬ 
fies  the  software  maintenance  requirements. 

6.  Verify  that  the  estimate  makes  sense. 

7.  Document  the  verified  estimate  and  stand  ready  to 
change  it. 


4.  Ccnstructiveness:  Can  a  user  tell  why  the  model 

gives  the  estimate  it  does?  Does  it  help  the  user 
understand  the  software  job  to  be  done? 

5.  Detail:  Does  the  model  easily  accommodate  the  esti¬ 

mation  of  a  software  system  consisting  of  a  number  of 
subsystems  and  units?  Does  it  give  accurate  phase 
and  activity  breakdowns? 

6.  Stability:  Do  small  difference  in  inputs  produce 

small  differences  in  output  cost  estimates? 


7. 


Scope  Does  the  model  cover  the  class  of  software 
projects  whose  cost  you  reed  to  estimate? 

8.  Ease  of  use:  Are  the  model  inputs  and  options  easy 

to  understand  and  specify? 

9.  Parsimony:  Dees  the  model  avoid  the  use  of  highly 

redundant  factors,  or  factors  which  make  no  appreci¬ 
able  contribution  to  the  results?  [Ref.  1:  p.  476] 

E.  DEPABTMENT  OF  DEFENSE  AND  SOFTWARE  COST  ESTIMATING 

Depa  tment  of  Defense  has  a  requirement  for  a  software 
cost  estimating  model  and  methodology  at  three  stages  cf  the 
software  lifecycle  [Ref.  28:  pp.  D19-22]. 

1.  Requirements  Analysis:  The  objective  here  is  to 

examine  long-range  costs  of  the  software  given  a  reasonable 
system  proposal.  Cost/risk  assessments  and  budgetary  esti¬ 
mates  are  performed  here.  Table  VII  shows  the  required 
inputs  and  outputs  of  such  a  model.  The  accuracy  required 
by  a  model  in  the  requirements  analysis  phase  is  less  than 
or  equal  to  50%. 

2.  Speci ficaticr  and  Design:  A  software  cost  esti¬ 

mating  methodology  can  be  used  to  assist  the  government  or 
contractor  in  estimating  the  costs  of  a  particular  system 
design  on  either  a  near-term  or  longer-term  lifecycle  cost 
basis.  The  majority  of  the  existing  models  take  this 
perspective.  Table  VIII  shows  the  required  inputs  and 
outputs  cf  such  a  model.  Estimate  accuracy  required  in  this 
phase  is  within  25%  of  the  actual. 

3.  Development,  Operations  and  Maintenance:  A  software 
cost  estimating  methodology  can  be  used  to  assess  the  cost 
impact  of  changes  during  the  development  phase,  and  estimate 
the  cost  of  implementing  a  change  during  the  operations  and 
maintenance  phase.  Table  IX  shows  the  required  inputs  and 
outputs  cf  such  a  model.  Required  model  estimate  accuracy  is 
within  10%  of  actual  values. 
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TABLE  711 

Model  Parameters  for  Requirements  Analysis  Phase 


INPUT  DATA 

System  Requirements 
performance 
testing 

Support  Philosophy 
maintenance 
manning 

Technology 

hardware 

software 


OUTPUT  DATA 

Long  Range  Budget 
Projections 
.system  R  5  D 
prototypes 
production  est. 
maintenance  est. 


Historical  System  Data  Base 
similar  systems 
similar  technologies 
similar  methodologies 


[Ref.  28:  p.  D21 ] 


A  major  element  of  the  DoD  Software  cost  estimation 
goals  is  establishing  a  reasonable,  representative  and  stan¬ 
dardized  methodology  [Ref.  28:  p.  D23].  DoD  should  not 
adopt  any  specific  model  and  declare  it  the  standard;  no 
model  offers  the  accuracy  required  by  DoD,  nor  does  any 
model  adequately  represent  each  phase  of  the  lifecycle 
[Ref.  19:  p.  5-29,  28:  p.  16].  Instead,  DoD  should 


....specify  the  general  procedure  for  estimating  soft¬ 
ware  costs  (i.e. ,  major  activities,  model  selection, 
model  documentation,  estimate  documentation  and  manage¬ 
ment  actions  required  to  use  the  results  of  any  software 
cost  estimation  effort).  The  establishment  of  this 
estimating  methodology  should  be  in  concert  with  the 
data  collection  goals  and  should  make  use  of  the  data 
collected  to  "fine-tune"  current  models  and  develop  new 
models.  The  model/methodology  developed  should  possess 
the  following  attributes:  [Ref.  28:  p.  24] 


TABLE  Till 

flodel  Parameters  in  Specification  and  Design  Phase 


INPUT  DATA 

System  Requirements 
erf ormance 
esting 

Documentation  Reqmts 
MIL-STD 
commercial 

Schedule  Requirements 

Support  Philosophy 
government 
contractor 
manning 

Cost  Estimates 
system  LCC 
hardware 
software 

actual  vs  predicted 

Technology 

hardware 

software 

Historical  Data 
similar  systems 
similar  technologies 
similar  methodologies 


[Ref.  28:  p.  D22] 


OUTPUT  DATA 


Long  Range  Budget 
Projection 
system  HDD 
prototypes 
production  est. 
maintenance  est. 

Mgmt  Support  Activities 
trade-off  analysis 
risk,  analysis 
resource  mix 
impact  assessment 
-schedule 
-personnel 

Development  Cost 
Estimates 
software 
hardware 
support 
maintenance 
documentation 
facilities 
manning 


j 


•  Open  discipline:  The  metaodology  should  be  flexible 

and  adaptable  to  specific  environments.  The  proce¬ 
dure  for  selecting  a  specific  model  should  allow  for 
the  exercise  cf  discretion. 

•  The  use  of  multiple  models:  The  methodology  should 

allow  for  the  employment  of  a  number  of  models  as 
required  by  the  lifecycle  phase  of  for  the 

appl ication . 
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TABLE  IX 

Model  Parameters  in  Development  and  Maintenance  Phase 


INPUT  DATA  Oj 

Schedule  M< 

Software 
Characteristics 
lines  of  code 
language 

complexity  3< 

Testing  Reguireraents 

Support  Tools 

support  software 
test  software 
support  personnel 

Test  Facility  Capabilities 


OUTPUT  DATA 

Manhours  by  Function 
design 
code 
test 

documentation,  etc. 
Schedule 


[Ref.  28:  p.  24] 


Reproducible:  The  methodology  used  should  yield  the 
same  estimate  of  cost  given  the  same  data  and 
situation. 


•  Living  methodclogy:  The  methodology  must  be  updated 

constantly  to  reflect  the  current  state  of  software 
technology.  This  is  achieved  through  institutional¬ 
izing  methodology  and  through  DoD  instructions,  regu¬ 
lations  and  standards. 

Desirable  characteristics  of  a  software  maintenance  cost 
model  include: 

1.  Automated  execution 

2.  Transportable  for  all  commonly  used  computers. 
Written  in  HOL. 


3. 


Model  algorithms  should  be  thoroughly  documented  and 
available  to  all  users. 

4.  Outputs  should  be  flexible  and  tailorable  to  several 
applicat ions. 

5.  The  total  set  of  models  should  cover  the  whole  soft¬ 
ware  lifecycle ,  although  individual  models  may  be 

specific  to  certain  phases  or  certain  applications  .. 

6.  Models  should  deal  effectively  with  missing  data. 

7.  Models  should  be  conservative  of  use  of  resources  for 
data  loading  and  computer  time  [Ref.  28:  p.  26]. 

Desirable  outputs  of  a  model  include: 

1.  Total  manpower  effort  by  phase  and  by  effort  type 

2.  Reasonable  development  time 

3.  Amount  of  documentation  required 

4.  Staffing  profile 

5.  Computer  costs 

6.  Cost-schedule  trade-off  factors 

7.  Sensitivity  of  output  to  input  variations 
'8.  Expected  maintenance  required 

9.  Milestone  occurance  times 

10.  Risk  Profile  [Ref.  28:  pp.  26-27] 

F.  THE  DEATH  OF  SOFTWARE 

An  early  objective  of  this  thesis  was  to  propose  a  model 
for  predicting  the  pcint  at  which  the  software  system  must 
he  replaced.  That  objective  was  beyond  the  scope  of  our 
effort.  Instead,  some  views  are  offered  on  what  to  think 
about . 

It  has  been  demonstrated  that  there  are  no  hard  and  fast 
rules  that  may  be  used  to  accurately  predict  the  lifespan  of 
a  system.  Many  factors  come  into  play,  and  the  influence  of 
any  factor  varies  considerably  from  system  to  system. 


In  general,  the  lifespan  of  a  system  may  be  sail  to  be  over 
if: 

•It  fails  to  adapt  to  change 

•It  is  replaced  by  another  system  performing  the 
same  function  £ Eef .  29:  p.  32]. 

While  replacement  of  software  is  conclusive  and  obvious, 
failure  of  software  to  adapt  to  change  requires  further 
explanation.  Four  primary  changes  [Ref.  29:  pp.  32-33]  may 
cause  the  death  of  a  software  system: 

1.  Hardware  changes:  Changes  of  this  nature  may  be  as 

catastrophic  as  the  replacement  of  the  entire 
computer  system  or  as  relatively  simple  as  the  expan¬ 
sion  of  peripherals.  In  either  case,  software 
systems  written  in  machine-specific  language  may  well 
be  doomed.  Even  so-called  "standard"  languages  like 
CCBCI  and  FORTRAN  are  not  immune,  there  being  almost 
as  many  versions  of  these  standard  languages  as  there 
are  computer  manufacturers.  Computer  manufacturers 
recognize  the  difficulty  of  converting  software 
systems  and  advertise  compatibility  between  their 
product  and  a  competitor's.  The  vendor's  definition 
of  compatibility  and  the  user's  may  differ  consider¬ 
ably,  however. 

2.  Software  changes:  All  software  systems  depend  upon 

others.  Applications  programs  depend  upon  ether 
programs  for  input  and  the  operating  system  for 
resource  control.  The  operating  system  in  turn, 
relies  upon  its  compilers  and  utilities.  A  major 
source  of  software  change  is  the  manufacturer's 
system  software,  the  package  of  operating  system  and 
associated  utilities  reguired  to  operate  the  computer 
system.  A  change  to  system  software  may  have  a 


catastrophic  impact  on  application  software  systems, 
but  usually  system  changes  occur  incrementally.  The 
application  system  must  therefore  adapt  to  each 
incremental  change,  or  risk  being  rendered  inoper¬ 
able. 

3.  Changes  in  requirements:  As  previously  noted, 

enhancements  due  to  user  requests  are  the  major 
source  of  software  maintenance.  Many  user  requests 
result  from  a  cnange  in  user  requirements,  often 
because  the  requirements  were  poorly  thought  cut  in 
the  original  design.  If  the  original  design  or  the 
software  system's  internal  factors  are  such  that 
modifications  cannot  be  made  to  meet  changes  in 
requirements,  the  system  falls  into  disuse  and  should 
be  replaced  with  a  system  that  can  be  evolved. 

4.  Chanqes  caused  by  errors:  All  software  contains 

errors.  Correcting  any  single  error  usually  intro¬ 
duces  0.5  further  errors  [fief.  29:  p.  33],  so  the 

error  correction  process  never  ends.  Software  that 
becomes  riddled  with  errors  is  abandoned  by  users, 
and  dies.  Sufficient  resources  must  be  applied  to 
the  correction  of  errors  to  keep  a  given  software 
system  viable  and  healthy. 

Given  that  software  must  change  in  order  to  survive,  how 
can  a  manager  economically  justify  any  given  change  in  the 
software?  How  does  a  manager  know  when  to  end  the  life- 
cycle  of  a  software  system  and  replace  it  with  another?  The 
answer  is  complex,  and  is  influenced  by  economic  factors, 
variable  (and  unknown)  user  requirements,  rapid  new  techno¬ 
logical  advancements  and  other  practical  considerations. 

The  perceived  benefit  of  the  existing  system  can  be 
thought  of  as  the  capabilities  of  the  system  and  the  value 
those  capabilities  have  within  the  organization.  This  is 
clearly  a  subjective  evaluation,  and  may  be  char acteri zed  as 
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"What  dees 


the  software  manager’s  answer  to  the  guestion: 
this  system  do  and  what  is  the  value  of  what  it  does  to  the 
organization?”  The  software  manager  must  then  compare  the 
benefit  cf  the  system  to  the  cost  of  operating  the  system. 
Ti.e  second  portion  of  the  decision  rule  deals  with  comparing 
tne  existing  system  with  the  proposed  replacement  in  two 
waps.  First,  the  marginal  cost  of  maintaining  tne  existing 
system  is  compared  to  the  marginal  cost  of  implementing  the 
proposed  replacement.  The  method  for  comparing  the  costs  of 
the  two  systems  is  probably  best  done  using  a  marginal  cost 
representation,  such  as  the  unit  cost  per  transaction. 
Second,  the  perceived  benefit  of  the  existing  system  is 
conpared  to  the  perceived  benefit  of  the  proposed  replace¬ 
ment.  The  replacement  system  must  be  at  least  as  caparie 
(i.e.,  egual  perceived  benefit)  as  the  existing  system. 

Cnee  the  decision  has  been  made  to  replace  tne  existing 
system,  the  software  manager  must  also  decide  the  timing  of 
the  replacement.  The  benefit  to  the  organization  (in  terms 
of  capital  and  resources)  of  keeping  the  existing  system  for 
one  more  year  should  be  compared  to  the  additional  capabili¬ 
ties  expected  from  the  proposed  replacement  if  implemented 
this  year. 

The  software  manager’s  replacement  decision  rule  may  be 
stated  as: 

If  the  perceived  benefit  of  the  existing  system  is 
exceeded  by  the  ccst  of  obtaining  that  benefit,  and  if 
the  marginal  cost  of  the  existing  system  exceeds  the 
marginal  cost  of  the  proposed  replacement  (including  a 
factor  for  reliability  problems  with  the  new  system), 
then  the  existing  system  should  be  rep  laced. 

It  is  implied  in  the  decision  rule  tnat  there  exits  the 
opportunity  cost  of  not  having  the  use  of  the  proposed 
replacement  that  must  also  be  considered. 
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In  the  past,  the  major  obstacle  to  replacing  a  system 
has  been  the  considerable  cost  and  uncertainty  involved  ir. 
developing  software  systems.  This  is  true  even  today.  The 
future  holds  promise, through  the  use  of  so-called  rourth- 
generaticn  languages  and  advanced  software  tools,  of  greatly 
reduced  development  cycles  and  considerably  enhanced  system 
rel iatil ity. 
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VI.  PERSONNEL  CONSIDER ATIO NS 


A.  I NTRCDOCTIOH 

The  DoD  Joint  Service  Task  Force  Report  on  Software 
problems  stated  that  "...  people  are  the  most  important 
resource  in  any  software  or  support  effort"  [Ref.  31:  p. 
24].  While  the  cost  of  hardware  plummets,  the  cost  of 
people  is  rising.  Ey  1985  the  cost  of  hardware  will  be  at 
one-tenth  the  1979  rate,  and  the  cost  of  people  will  be  at 
twice  the  1979  rate  [Ref.  32].  With  manpower  as  the  domi¬ 
nant  element  of  cost  in  performing  software  mainterance, 
the  software  manager  must  better  understand  the  critical 
aspects  of  personnel  management  in  software  maintenance. 
Considerable  gains  can  be  achieved  through  effective  manage¬ 
ment  of  maintenance  personnel  and  of  the  maintenance  func¬ 
tion.  The  personnel  issue  will  be  examined  from  two 
perspectives;  that  of  skills  and  attributes  are  required  in 
a  maintenance  programmer,  and  how  to  best  organize  mainte¬ 
nance  personnel  to  accomplish  the  maintenance  function. 

B.  SKILLS  AND  EXPERIENCE  NEEDED  IN  SOFTWARE  MAINTENANCE 

The  skills  and  experience  required  by  the  maintenance 
programmer  are  well  summarized  by  a  auote  from  the  Pebbleman 
document . 1 

Tc  make  this  situation  vivid,  consider  a  navigation 
module  on  a  supersonic  aircraft.  Let  us  suppose  that 
the  navigation  module  is  supposed  to  provide  the  correct 
position  of  the  aircraft  to  within  10  meters  anywhere  in 

lFebtleman  is  one  of  a  series  of  Department  of  Defense 
(DoDI  analysis  papers  which  lead  to  the  creation  of  the  DoD 
standard  language,  Ada.  Ada  is  a  registered  trademark  of 
the  U.S.  Department  of  Defense  [Ref.  33]. 
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phere  of  the  earth.  The  module  obtains  input 
s,  accelerometers,  clocks,  doppler  radars  and 
n  signal  receptors  which  can  listen  to  satel- 
ground  station  signals.  Suppose  it  has  been 
d  (perhaps  by  exercise  of  self- diagrosin g 
monitoring  procedures  and  execution  of  fault- 
decision  trees)  that  none  of  the  input  devices 
malfunctioning.  But  suppose  that  the  results 
by  the  module  are  consistently  in  error. 


let  us  further  suppose  that  the  actual  error  is  a 
superimposition  of  errors  from  three  separate  sources: 
(1)  a  simple  programming  error  involving  unintentional 
clobbering  of  'the  contents  of  a  global  variable  by  a 
local  procedure  which  incorrectly  assumes  that  the 
global  variable  is  local,  (2)  the  decay  in  numerical 
accuracy  of  a  certain  class  of  computations  through 
inadequate  numerical  analysis  of  error  propagation,  and 
(3)  failure  to  design  the  module  to  take  account  of 
coriolis  force,  leading  to  systematic  errors  on  north- 
south  trajectories  at  high  mach  numbers. 

Each  of  these  error  sources  might  fall  within  the 
province  of  distinct  skills  at  the  command  of  distinct 
trained  specialists.  Only  a  physicist  familiar  with  the 
laws  of  kinematics  and  dynamics  might  be  expected  to 
realize  and  correct  the  coriolis  force  error.  Only  a 
numerical  analvst  familiar  with  the  laws  of  numerical 
error  propagation  might  be  expected  to  discover  and 
correct  the  error  of  numerical  accuracy  decay.  And  only 
a  programmer  trained  in  the  use  of  nomenclature  scope 
rules  in  the  programming  language  used  to  implement  the 
module  might  be  expected  to  discover  and  correct  the 
error  of  unintentional  information  clobbering. 

If  the  actual  error  is  a  superimposition  of  these 
sorts  of  errors  at  these  three  sorts  of  levels  of 
program  logic,  it  is  doubtful  that  a  maintainer,  trained 
only  in  one  of  the  three  relevant  skills,  could  succeed 
in  untangling  the  superimposed  errors,  in  isolating 
their  sources,  and  in  making  appropriate  corrections. 

In  a  similar  vein,  if  the  system  is  being  enhanced  to 
meet  new  requirements,  the  skills  of  requirement 
analysts  and  designers  may  be  required  to  modify  the 
requirements  and  the  design  incrementally  and  to  brina 
the  requirements  and  design  documents  up-to-date  consis- 
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presence  of  more  constraints,  incremental  reanalysis  and 
redesign  might  be  more  difficult  than  original  analysis 
and  desiqn.  It  may  not  be  enough  for  the  maintainer 
skilled  only  in  the  implementation,  test,  and  integra¬ 
tion  phases  of  the  software  life  cycle  to  perform  acts 
of  enhancement  that  call  for  the  replay  of  skills  exer- 
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cised  by  teams  of  skilled  specialists  at  earlier  life 
cycle  phases  —  teams  now  disbanded  and  unavailable. 
This  is  particularly  likely  to  be  true  if  the  require¬ 
ments  and  design  levels  or  the  system  being  enhanced 
demand  skilled  thinking  in  application  domains  widely 
separate  from  programming. 

But  we  know  that  maintenance  and  enhancement  may  tend 
to  occur  under  circumstances  under  which  the  original 
teams  that  performed  the  high  level  logic  analysis  and 
design  (and  which  used  special  application  domain  skills 
remote  from  programming  skills)  have  long  since 
disbanded,  leaving  maintenance  and  enhancement  tasks  to 
those  unskilled  in  the  higher  logic  levels  of  the 


system.  Such  maintenance  circumstances  are  unpropiticus 
unless  techniques  can  be  found  to  determine  when  to  call 
in  cr  recongregate  teams  of  skilled  specialists  needed 
for  fault  detection,  repair,  cr  enhancement.  [Ref.  7] 


Thus,  to  summarize,  a  maintenance  programmer  must  be  a 
highly-skilled  individual  with  the  following  qualities: 

1.  Skilled  in  the  programming  language  used  in  the 
activity  and  well-versed  in  obscure  features  whose 
use  by  development  personnel  may  hide  subtle  errors. 

2.  Knowledgeable  in  the  function  of  the  system  and  able 
tc  detect  errors  in  logic. 

3.  Possess  the  keen,  incisive  mind  of  a  detective  who 
enjoys  the  challenge  of  sifting  through  obscure 
clues. 

4.  Possess  all  the  skills  required  in  software  develop¬ 
ment,  including  those  of  the  requirements  analysts, 
system  designers  and  technical  writers  (to  update  the 
documentation)  . 

5.  Be  determined  and  optimistic. 

6.  Have  a  keen  awareness  of  human  psychology  in  order  to 
understand  the  logic  of  the  original  development 
programmer. 

Unfortunately,  the  maintenance  programmer  rarely 
embodies  all  these  qualities.  Normally,  he  or  she  is  rela¬ 
tively  inexperienced  and  new  at  the  organization. 
Programmers  were  often  started  out  in  software  maintenance 
to  train  them  for  the  "real  job"  of  software  development.  A 
programmer  is  thrust  into  working  on  old  software  systems 
running  on  obsolete  equipment  and  managed  in  a  crisis  mode. 
The  novice  programmer  learns  to  patch  systems  "to  keep  them 
running",  gaining  little  job  satisfaction  and  rarely  seeing 
a  jot  well  done  and  completed  as  his  counterpart  in  develop¬ 
ment  would.  As  patches  accumulate  upon  patches,  the  system 
gradually  deteriorates. 


A  reason  that  software  maintenance  has  become  the  heme 
of  the  inexperienced  and  the  ineffective  lies  in  the  poor 
connotation  of  the  term  "maintenance".  The  problem  of 
management  perception  and  the  status  of  maintenance 
personnel  was  a  serious  point  of  discussion  in  the  session 
on  Management  of  Software  Maintenance  at  the  Software 
Maintenance  Workshop,  held  at  the  Naval  Postgraduate  School, 
Monterey,  California,  December  6-3,  1983.  Maintenance  in 

the  physical  sense  implies  simply  repairing  the  structure 
without  making  any  real  changes,  something  akin  to  scrapping 
the  rust  off  a  bridge.  That  is  hardly  tne  case  in  software 
maintenance.  It  has  teen  shown  that  software  maintenance  is 
largely  designing  and  implementing  user- requested  enhance¬ 
ments,  an  activity  very  similar  to  system  development 
although  lacking  the  advantages  of  a  dedicated  and  trained 
development  staff.  The  correction  of  failures,  the 
"scraping  off  the  rust",  is  only  a  small  part  of  the  total 
software  maintenance  picture.  Software  maintenance  is  a 
highly  demanding  and  vital  function,  fully  deserving  of 
management  recognition.  Management  must  take  steps  to 
recognize  the  importance  of  software  maintenance  and  enhance 
the  status  of  the  maintenance  programmer. 

Seme  psychological  testing  would  seem  to  be  appropriate 
to  test  the  individual  for  seme  or  all  of  these  beneficial 
or  hindering  traits.  Schneiderman  highlights  some  of  the 
tests  in  use,  but  also  notes  that  our  understanding  of  them 
is  shallow  [Ref.  34:  pp.  57  -  62  ].  Some  of  the  tests  avail¬ 
able  include: 

•  Myers-Priggs  Type  Indicator  (METI)  which  gives  insight 
into  the  personality  dimensions  of  the  programmer  of 
ex  trovers ion/ intro vers ion,  sensing/ intuition, 

thinking/feeling,  judging/perception.  "he  interac¬ 
tions  of  these  pairings  of  traits  is  more  important 
than  the  preference  itself. 


•  Minnesota  Multiphasic  Personality  Inventory  (MMFI) 
which  is  used  to  determine  information  about  the 
person’s  desire  to  please#  honesty  and  candor. 

•  Strong  Vocational  Interest  Blank  (SVIB)  which  matches 


the  individual’s  likes  and  dislikes  with  other  members 
of  specific  professions. 

•  Computer  Programming  Aptitude  Battery  (CPAB)  tests 
verbal  meaning#  mathematical  reasoning,  letter  sense# 
number  ability#  and  diagramming  skill. 

•  Berger  Test  of  Programming  Proficiency  (BTOFP)  is 
designed  to  measure  an  individual’s  knowledge  and 
proficiency  in  the  basic  principles  and  technigues  of 
programming  [Kef.  34:  p.  61]. 

Validation  and  improvement  of  these  and  other  tests  are 
still  reeded. 

The  development  and  availability  of  personnel  with  the 
proper  skills  is  nc  small  matter.  All  personnel  are 
confronted  with  the  problem  of  maintaining  currency  in  a 
rapidly  changing  technology.  In  the  data  processing  commu¬ 
nity  in  general  demand  exceeds  supply#  but  within  the 
Department  of  Defense  the  problem  has  added  dimensions 
[  ef.  31]  that  arise  from  the  three  areas  where  the 
personnel  may  be  drawn,  namely:  the  military,  civil  service 
or  contractors. 

1 .  Military 

The  service  policy  of  rotating  officers  every  two  to 
three  years  reduces  and  disrupts  the  supply  of  qualified 
personnel.  This  is  exacerbated  by  the  Army  and  Navy  policy 
of  also  rotating  those  officers  trained  in  data  processing 
into  and  out  of  assignments  far  removed  from  the  computer 
field. 


Cn  the  enlisted  side  the  problems  are  intensified 
due  to  lucrative  employment  opportunities  within  industry. 
Cnee  an  individual  is  trained,  the  prospects  of  high-paying 
jobs  cn  the  outside  are  very  good.  A  'J.  S.  Air  Force  study 
[Sef.  35:  pp.  1-5]  revealed  that  the  second  term  retention 
rate2  is  only  about  50%  for  certain  computer  resource 
skills. 

2 •  Civil  Service 

Although  the  Joint  service  report  [Sef.  31]  is 
directed  at  the  entire  life  cycle  of  embedded  computer 
systems,  the  problem  of  availability  of  skilled  personnel  is 
still  the  same  for  computer  software  maintenance  in  general. 
For  the  civil  service  work  force,  maintenance  personnel  must 
stay  current  in  a  number  of  closely  related  fields, 
including  computer  science  and  engineering,  but  the  means  to 
do  so  may  be  thwarted  by  government  employment  regulations. 

....The  personnel  problem  is  exacerbated  by  the  limita¬ 
tion  of  most  entry  level  and  middle  technical/management 
civil  service  positions  to  the  Engineering  (GS-800) 
series  in  the  Commands  that  aeguire  ECS  [embedded 
commuter  software].  This  excludes  computer  science  an¬ 
other  related  degree  fields  from  oursuing  careers  or 
shifting  to  careers  involving  ECS*  aeguisition.  It 
should  be  noted  that  Civil  Service  regulations  currently 
prohibit  advertising  a  position  as  interdisciplinary 
when  one  of  the  disciplines  is  a  "Professional"  series 
(as  is  the  GS-800  Engineering  Series).  [Ref.  31:  p.  25] 

From  another  report  on  maintenance  in  the  commercial 
sector,  Lientz  gives  a  figure  of  20-30%  shortage  nationally 
of  systems  personnel  [Ref.  36:  p.  9].  Lientz  suggests  that 
users  may  have  to  fill  in  this  gap  between  the  supply  and 
demand  of  programming  personnel,  but  that  can  only  happen  if 
advanced  software  tools,  such  as  fourth  generation 


2A  second  term  retention  refers  to  an  individual  makinc 
a  second  obligation  to  military  service  after  the  completion 
of  the  first  term  of  enlistment  normally  4-6  years. 
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languages,  are  available  to  simplify  the  task, 
discussed  in  the  next  chapter. 

3 .  Contractors 

The  problems  with  military  and  civil  service  labor 
cften  forces  a  heavy  reliance  on  contractors.  This  depen¬ 
dency  on  contractors  has  problems  of  its  own. 

•  The  contract  performance  must  still  be  monitored  by 
someone  knowledgeable  in  the  field. 

•  Contractor  personnel  must  be  trained  in  the  system. 
This  may  become  counter-productive  as  turnovers  within 
the  contractor's  organization  occur  over  which  the  mili¬ 
tary  manager  has  no  control  or  when  a  contract  is  not 
renewed. 

•  The  required  competition  for  renewal  of  a  contract  and 
possible  loss  to  another  firm  drains  the  corporate 
knowledge  regarding  the  system. 

•  The  use  of  contracted  software  creates  long  learning 
curves  when  training  personnel  to  maintain  any  specific 
system. 

C.  J? EESCNNEL  ATTRIBOTES 

The  specific  interdependent  personnel  attributes 
required  for  the  maintenance  programmer  go  a  long  way  to«  ::1 
forming  the  maintenance  programmer  in  somewhat  the  same  a; 
as  a  development  programmer,  but  with  a  twist.  f  s  has  '• 
discussed  earlier,  the  familiarity  wita  the  application,  t..s 
language  and  the  hardware  environment  are  still  important, 
but  in  the  case  cf  the  maintenance  programmer  fcr  a 
different  underlying  reason.  The  maintainer  is  often  called 
upon  to  fix  a  system  in  a  crisis  mode  or  try  to  deal  with  a 
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system  that  has  little  if  any  documentation.  Ar.  ideal  would 
te  tc  have  the  programmer  or  just  someone  who  participated 
in  the  design,  available  to  respond  when  the  documentation 
is  inadeguate  (if  there  is  even  documentation  at  all).  As 
can  be  seen,  the  maintenance  programmer  is  a  different  kind 
of  programmer  with  different  productivity  measures  than  can 
be  advocated  on  the  development  side  where  the  programming 
team  approach  is  to  produce  '’egoless"  programming  from  a 
democratic  group  approach  of  a  joint  effort  [Ref.  37].  This 
encourages  the  exchange  of  ideas  and  reduces  the  ownership 
cf  programs. 

Glass  suggests  that  the  maintenance  programmer  will 
always  remain  the  bastion  cf  the  individual  worker 
[Ref.  23],  The  individual  certainly  must  respond  to  any 
number  of  applications  with  a  detective's  curiosity  tc  find 
clues  to  the  problem  where  they  are  not  readily  available. 
In  maintenance  work  there  is  much  more  of  an  interface  with 
the  user  creating  immediate  feedback  and  frequent  rewards 
when  the  users  are  happy.  Martin  and  McClure  carry  this 
further  saying  there  is  a  place  for  the  team  approach  still 
in  maintenance  programming  [Ref.  25:  pp.  429-435].  This 
approach  can  help  the  training  of  maintenance  programmers  as 
weli  as  exchange  of  ideas  on  the  various  applications  for 
which  the  group  is  responsible.  A  complement  to  the  team 
approach  is  presented  in  [Ref.  38],  and  suggests  that 
support  personnel  such  as  a  librarian  to  monitor  and  main¬ 
tain  the  documentation  and  a  archivist  to  monitor  and  main¬ 
tain  file  updates  are  needed.  The  "egoless"  attitude  of 
getting  the  opinion  cf  another  programmer  on  a  problem  or 
the  implementation  of  a  change  should  help  to  produce  more 
error-free  programming  as  well  as  being  a  good  learning 
tool.  One  drawback  still  may  be  the  size  of  the  maintenance 
organization.  A  very  small  maintenance  shop  may  not  have  as 
many  opinions  available  to  draw  on  though  the  attitude  could 
still  be  there. 
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D.  A  flAINTENANCE  PROGRAMMER  PERSONALITY  PROFILE 

The  result  of  all  of  the  questions  of  the  organization 
of  the  personnel,  and  who  is  available  to  do  what,  may  leave 
hanging  the  identity  of  the  individual  involved  in  this 
activity.  From  tne  many  references,  it  would  seem  that  this 
individual  must  have  good  sound  judgement,  vast  experience 
and  technical  expertise,  the  ability  to  identify  the  needs 
of  the  user,  great  understanding  of  existing  software  and 
technical  versatility.  3ut,  why  is  this  multi-talented 
individual  made  to  be  the  inferior  to  the  development 
programmer?  The  exact  reasons  don't  need  to  be  defined,  tut 
the  concept  has  grown  through  a  process  of  evolution  partly 
as  a  result  of  the  definition  of  the  term  "maintenance" 
programmer  discussed  in  Chapter  II. 

Bronstein  and  Okamoto  propose  that  there  really  are 
separate  types  of  individuals  that  should  be  working  in  the 
development  and  maintenance  areas  [Ref.  39],  This  break  is 
to  be  on  the  balance  between  an  individual's  "communication 
styles".  From  [Ref.  39]  Figure  6.1  shows  the  four  different 
psychic  functions  that  combine  to  produce  profiles  of  indi¬ 
vidual's  attitudes,  assumptions  and  reactions  that  make  one 
more  appropriate  for  different  types  of  jobs.  A  definition 
of  the  terms  from  Figure  6.1  are: 

•  Analyzer  {thicker)  places  high  value  on  facts  and 
figures  and  is  good  on  judging  relationships  of 
things;  wants  to  be  in  control  of  work. 

•  Affiliator  (feeler)  places  high  value  on  personal 
relationships;  is  flexible  and  thought  of  as  a 
supporter . 

•  Activator  (sensor)  places  high  value  on  the  here  and 
now;  is  assertive;  and  therefore,  supports  time 
constraints. 


Conceptualizer  (intuitor)  places  a  hign  value  on 
knowing  the  nature  of  things  in  terns  of  their  overall 
significance. 


The  level  of  each  of  these  four  functions  may  he  ques¬ 
tioned  in  relationship  to  the  splits  giver,  in  Figure  6.  1  , 
hut  there  still  points  to  the  realization  that  according  to 
!  one's  cc mmur.ication  style,  a  programmer  may  t e  more  suited 

for  the  maintfenar.ee  environment  as  opposed  to  the  develop¬ 
ment  environment.  Finding  the  individuals  who  are  motivated 
and  lest  suited  for  this  tyre  cf  work  will  aid  the  manager 
I  in  having  competent  and  productive  employees. 

The  detailed  example  given  at  the  beginning  cf  this 
chapter  applies  to  the  military  tactical  side  of  program¬ 
ming,  but  the  variety  of  problems  that  any  maintenance 
1  programmer  will  have  to  face  will  also  cover  the  whole  gamut 

cf  activities  of  that  specific  organization.  Another 
example  may  be  that  of  a  space  surveillance  organization 
which  could  involve  the  fields  of  orbital  and  space  physics, 
E  high  level  mathematics,  intelligence  processing,  communica¬ 

tions,  etc.  as  well  as  data  processing;  a  supply  organiza¬ 
tion  could  involve  inventory  control,  budgeting  and 
financial  management,  accounting,  purchasing,  etc.  along 
|  with  data  processing. 

Some  solutions  can  be  seen  in  both  getting  better  people 
in  these  positions  as  well  as  giving  them  better  tools, 
environment  and  prestige  in  the  work  place. 

« 

E.  OBG AHIZATION 

There  has  long  been  a  discussion  of  the  organization  of 
^  the  personnel  involved  in  the  various  programming  activi¬ 

ties.  This  is  as  shewn  in  the  1972  discussion  in  [Bef.  40] 
of  whether  to  have  a  separate  programming  organization 
devoted  to  maintenance  entirely  separate  from  the  group 


Figure  6.1  Coaaunication  Styles. 
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devoted  to  the  development  process.  Ti 
both  these  areas  provide  no  definitive 
either  approach.  V’hen  the  same  group 
involved  in  both  the  design  and  mainl 
there  is  a  lot  of  cross  training  going 
any  change  easier  to  implement. 

Cn  the  one  hand,  current  research  ini 
the  ’Software  Crisis'  [Ref.  3,  11,  33] 

finding  better  ways  to  accomplish  and  mai 
process.  Methodologies  such  as  So; 

Engineering  Methodology  (SEEM)  developed 
Ballistic  Missile  program  [Ref.  41]  and  ! 

Design  Technique  (SADI)  3  [Ref.  42]  are  c 
this  area  and  have  aided  in  providing  an 
the  development  process.  These  methoaoic 
and  others  combine  methods  and  tools  wii 
aid  in  accomplishing  the  development  process,  such  as  to 
decompose  the  software  into  modules,  provide  a  graphical 
notation  and  control  guidelines,  sometime  with  the  aid  of 
computer  software  system  [Ref.  43].  On  the  other  hand  very 
little  of  this  has  been  done  in  the  maintenance  arena, 
area  is  only  now  getting  the  attention  it  deserves. 
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VII.  TOOLS  AND  STANDARDS 


A.  INTRODUCTION 

The  resource  of  personnel  is  a  dominant  factor  influ¬ 
encing  software  evolution.  In  the  face  of  personnel  demand 
outstriping  supply,  the  software  maintenance  manager  must 
obtain  the  maximum  benefit  from  available  resources.  A 
means  of  achieving  this  is  through  the  integration  cf  soft¬ 
ware  tools  into  the  maintenance  effort.  A  software  tool  is 
an  automated  program  or  process  that  enhances  or  replaces 
human  effort.  In  Chapter  III,  Figure  2.1,  it  is  pointed  cut 
that  the  bulk  of  a  maintenance  programmer's  time  (nearly 
50'^)  is  spent  in  trying  to  understand  the  existing  software 
system.  Thus,  tools  that  can  aid  the  programmer  in  under¬ 
standing  software  should  be  addressed  first  by  the  software 
maintenance  manager.  Testing  to  maintain  the  integrity  of 
the  system  is  also  a  large  part  of  this  process,  which  can 
also  be  aided  through  the  use  of  automated  tools.  The 
following  discussion  relates  the  availability  and  use  of 
tools  for  the  maintenance  environment  where  it  can  improve 
programmer  productivity. 

E.  SYSTEM  VIEW 

A  mere  thorough  view  of  the  relationship  between  these 
activities  and  the  tccls  available  is  in  order,  while  still 
considering  the  personnel  issues  addressed  in  the  last 
cnapter.  The  tools  addressed  here  are  for  the  most  part 
automated  tools.  While  most  of  these  tools  discussed  were 
created  for  the  development  environment  rather  than  mainte¬ 
nance,  they  are  still  very  applicable  to  the  maintenance 
programming  function.  A  DoD  report  [Ref.  31:  p.  A- 39] 
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purports  that  in  a  total  view  of  the  system,  there  can  Le  a 
dramatic  impact  cn  software  problems  achieved  through 
support  tools  having  five  bread  objectives.  These  objec¬ 
tives  are: 

1 .  Integration 

This  is  designed  to  provide  an  interface  with  the  entire 
environment  viewed  as  cooperating  functions. 

2 .  Suppor t 

This  brings  the  entire  life  cycle  of  the  software  together 
especially  implementing  and  validating  tne  changes  after  a 
system  is  designated  operational. 

3 .  Standard izat icn 

In  this  rapidly  expanding  world  of  computers,  standards  are 
designed  for  ease  of  transportation  across  a  number  of  host 
processors. 

4 .  Support  of  Standard  Languages 

Within  DcD  or  any  specific  organization  tae  designated  stan¬ 
dard  languages  must  be  supported  by  tools.  In  other  words, 
completely  language  and  machine  portable  support  tccls  are 
not  required. 

5 .  Flexibility  and  Maintainability 

The  tool  itself  must  also  be  flexible  and  maintainable 
within  the  environ me  rt  to  ease  the  evolutionary  changes . 

C.  TCOLS 

Software  tools  must  therefore  match  the  organization 
within  which  they  are  to  be  found.  This  is  a  broad  state¬ 
ment  addressing  the  large  variety  of  sizes  of  data 
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processing  crganiza  ticns  that  can  be  found  eve: 
authors'  cvr.  experience  within  DoD.  One  ma; 

with  software  written  in  assembler  languages 
hardware  all  the  way  up  to  systems  provided  ii 
languages  using  state-of-the-art  hardware 
technologies. 

To  avoid  overly  emphasizing  either  end  of  tl 
the  authors  are  presenting  some  broad  views  o 
may  be  helpful  avoiding  too  much  detail  at  e: 
this  spectrum.  The  availability  of  some  specif, 
may  meet  the  needs  cf  a  specific  environment  . 
by  type  and  vendor  in  a  table  in  [Ref.  25:  pp. 
in  [Ref.  4:  pp.  4-2  -  4-10],  A  more  current  i 
the  type  and  availability  of  tools  may  be 
numerous  trade  journals,  a  preferred  source  in 
changing  computer  world.  A  list  of  sources  t< 
found  in  appendix  A.  A  comprehensive  list  of  s< 
would  net  he  feasible  nor  desirable,  as  it  wou 
obsolete . 

These  tools  though  can  help  deal  with  pas 
styles.  This  is  not  a  criticism  of  past  pra^ 
understanding  of  some  of  the  problems  facing  t, 
today.  These  include  from  [Ref.  39]  : 

•  Maintaining  programs  written  without  stan 

•  Lack  cf  documentation  and  source. 

•  Different  computers  and  languages. 

D.  TIEES  CF  TOOLS 

Candidate  areas  for  types  of  automated 
specific  organization  are  suggested  in  the 
[Ref.  31],  and  the  Martin  and  McClure  book  [Ref 
may  be  categorized  as: 
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1.  Scf tvare  doc amenta tior. ,  such  as  structure  charts 
flowcharts  and  cr oss-referencing. 

2.  Testing  and  debugging  tools. 

3.  Software  libraries. 

4.  High  order  languages  (HC1)  . 

5.  Configuration  management. 

6.  Data  base  management  systems. 

7.  Management  information  systems. 

3.  Analysis  tools,  such  as  simulation  and  diagncsti 
aids . 

A  rule  of  thumb  for  the  manager  may  be  to  step  throug 
this  list  of  types  of  tools  that  may  be  available  and  may  b 
applicable  to  the  specific  organization.  Certain  old  hard 
ware  configurati.ons  may  have  few  choices  of  actual  tool 
that  are  available.  In  the  same  light,  old  operatin 
systems  or  software  languages  may  not  be  supported  in  sen 
areas.  In  any  case  items  1  to  4  can  aid  specifically  i 
improving  the  maintenance  programmer's  understanding  cf  th 
existing  system. 

The  wide  variations  in  specific  functions  that  may  ais 
te  addressed  are  shewn  in  Table  X  from  the  national  3urea 
of  Standards  Special  Publication  500-74,  "Features  o 
Software  Development  Tools"  reproduced  in  £Bef.  44] 
Suggestions  for  the  development  of  new  advanced  tools  tha 
may  overcome  some  cf  the  problem  areas  mentioned  ar 
presented  in  [Bef.  6]. 

Table  XI  from  [ Hef .  25:  p.  411]  is  presented  to  show 
relationship  between  the  types  of  tools  available  and  th 
quality  characteristics  of  the  software.  An  emphasis  withi 
the  organization  for  specific  areas  of  improvements  wil 
force  a  manager  to  actively  seek  out  one  or  more  types  o 
tools.  Some  examples  of  these  types  of  commercially  avail 
able  tools  are: 

•  static  analyzer  -  Amdahl's  MAP 
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TABLE  X 

Tool  Function  Taxonomy 


Transformation 

Static  Analysis 

Dynamic  Analvs 

Editing 

Auditing 

Assertion  Chec 

Formatting 

Comparison 

Constraint 

Instrumentation 

Complexity 

Evalu  ation 

Optimization 

Measurement 

Coverage  Analy 

Restructuring 

Completeness 

Resource 

Translation 

Checking 

Consistency 

Checking 

Cost  Estimation 
Cross  Reference 
Data  Flow 

Analysis 

Error  Checking 
Interface  Analysis 
Management 

Resource  Estimatio 

Utili  zaticn 

S imulat ion 
Symbolic 

Execu  tion 

T iming 

Tracing 

Tuning 

Scanning 

Scheduling 

Statistical  Analysis 
Structure  Checking 
Tracking 
Type  Analysis 
Units  Analysis 


•  structure  checker  -  TRW's  CODE  AUDITOR 

•  cress  reference  listers  -  TRW's  DEPCHT,  DPNDCY  and 
FREF 

•  automatic  doc  menter  -  General  Research  Corp.'s  RXTP 

•  automatic  flowcharter  -  TRW's  FLOWGEN 

•  structuring  engine  -  Catalyst  Corp.'s  COBOL  Engine 

•  executive  and  performance  monitor  -  TRW's  PPE 


TABLE  XI 

Software  Quality  Measurement  Tools 


Quality  Characteristic  Measurement  Tool 


1.  Understandability* 

2.  Reliability 

3.  Testability* 

4.  Modifiability* 

5.  Portability 

6.  Efficiency 


Structure  checker 
Automatic  flowcharter 
Execution  path  tracers 
Automatic  complexity  analyzer 

Execution  path  tracer 
Automatic  complexity  analyzer 

Automatic  flowcharter 
Execution  path  tracer 
Automatic  complexity  analyzer 

Automatic  complexity  analyzer 

Standard-language- vers  ion 
compiler 

Structure  checker 

Structure  checker 
Performance  monitor 


*  Defined  as  requirements  for  maintainability 


E.  ENVIBCHHEHTS 

A  list  of  the  different  types  of  tools  that  may  be 
needed  within  an  organization  is  a  good  start  for  the 
manager.  The  manager  may  then  develop  a  list  of  those  tools 
that  are  available  for  a  specific  environment,  namely  the 
computer  hardware  in  use,  the  software  languages  being  used, 
the  database  systems  available,  etc.  These  two  lists  may 
not  overlap  at  all,  and  what’s  more,  the  tools  that  are 
available  may  not  work  with  each  other.  For  this  reason, 
there  is  developing  a  strong  emphasis  on  making  available  an 
environment  that  includes  the  tools  needed  for  the  computer 
language  in  use  and  compatibility  with  a  variety  of  hardware 
manufacturers.  Two  environments  under  development  are 


specified  here  with  seme  problem  areas  discussed.  One  is 
termed  'Program  Manager'  and  the  other  is  tied  to  the  DoD 
language  Ada. 

Cne  of  the  greatest  problems  within  DoD  is  the  use  cf 
obsolete  hardware  for  which  no  tools  exist.  The  question 
then  becomes  whether  it  is  cost  effective  to  retrofit  the 
new  tool  to  the  old  hardware  or  not.  Unfortunately,  the 
answer  is  usually  no,  but  the  question  must  be  answered  on  a 
case-by-case  basis. 

1  •  Programming  Manager 

Dean  and  McCune  [Ref.  6]  and  others  state  a  need  for 
a  maintenance  programming  environment.  A  programming 
manager  could  be  an  integrated  tool  that  would  help  improve 
the  program  development  and  maintenance  process  by  ensuring 
the  systematic  application  of  managerial  and  technical  poli¬ 
cies  and  methodologies.  There  are  three  particular  problem 
areas . 


a.  Standards  and  Policy 

Management  policies  and  standards  are  designed 
to  promote  quality  and  reliability  of  the  software  as  well 
as  minimize  the  retraining  required.  Unfortunately,  the 
volume  and  complexity  of  the  standards  and  policy  are  such 
that  they  are  often  ignored.  Policy  should  be  clear,  direct 
and  brief.  Standards  should  be  logically  organized,  indexed 
and  ustable. 

t.  Systems  Details 

As  a  programmer  is  working  on  a  large  system,  a 
lot  of  time  is  spent  learning  how  the  system  works.  The 
programmer  learns  the  minute  details  of  how  the  system  works 
through  the  process  cf  modifying  and  debugging,  tut  then 
promptly  forgets  this  detail  as  work  goes  on  into  another 


project.  The  usual  methods  cf  recording  information  in 
manuals,  reports  and  memos  is  often  not  appropriate  for  this 
low  level  of  information  yet  it  is  still  vitally  important 
to  the  maintenance  function. 

c.  Programming  Environment 

Host  programming  environments  have  a  number  of 
tools  available  for  use.  Some  of  these  are  absolutely 
necessary  and  familiar  to  the  programmer,  such  as  editors 
and  compilers.  A  variety  of  other  tools  may  be  available, 
but  not  well-known  to  the  programmers.  Manuals  and  on-line 
documentation  provide  very  little  help  in  this  case  since 
the  programmer  must  explicitly  request  the  tool.  If  the 
programmer  has  forgotten  or  doesn’t  know  about  them,  they 
will  remain  unused. 

2.  Ada  Programming  Support  Environment 

Booch  describes  in  [Ref.  33]  the  specific  environ¬ 
ment  being  developed  for  the  new  DoD  language,  Ada.  This 
environment  is  referred  to  as  the  Ada  Programming  Support 
Environment  (APSE).  The  Ada  language  and  environment  now 
being  developed  within  the  DoD  is  required  for  embedded 
computer  systems  only,  thus  far.  (In  the  non-embedaed 
systems  there  still  is  a  need  for  some  sort  of  program  envi¬ 
ronment  unless  Ada  becomes  workable  for  both.) 

The  Ada  Programming  Support  Ervironraent  seeks  to 
support  the  system  through  its  whole  life  cycle  with  the 
expectations  from  [Ref.  45]  of: 

•  reducing  compiler  development  costs 

•  reduced  tool  development  costs 

•  improve  software  portability 

•  improve  programmer  portability 


£  l 

Figure  7.1  The  Ada  Programming  Support  Environment. 

The  architecture  or  the  Aia  Programming  Sufpcit 
Environment  is  shown  in  Figure  7.1  from  [Ref.  46].  The 
central  point  of  control  is  provided  for  the  project  manager 
through  the  program  data  base.  The  data  Lose  pnysically 
exists  at  the  inner  le-vel  of  the  tnviror.it  i.t  m  the  Host 
Operating  system. 
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a.  KAPSE 

The  Kernel  Ada  Programming  Support  Environment 
(XAPSE)  is  the  next  level  which  provides  the  logical  to 
physical  mapping  for  the  APSE.  This  provides  the  most 
elementary  reguirements  for  run-time  support.  This  support 
of  the  logical/physical  mapping  is  the  needed  portability 
for  the  program.  Theoretically  then,  the  KAPSE  would  be  the 
only  i  up  lenient  ation- dependen  t  change  needed  for  rehcstirg  an 
environment. 


b.  MAPS  E 

Above  the  KAPSE  is  the  Minimal  Ada  Programming 
Support  Environment  (MAPSE)  which  contains  a  minimal  set  of 
tools  for  program  development,  and,  of  course,  maintenance. 
As  defined  by  STO NEMAN  [Ref.  47],  the  MAPSE  contains 
suggested  tools  such  as: 

•  text  editor 

•  pretty  printer  (code  fonater) 

•  compiler 

•  linker 

•  set-use  static  analyzer 

•  dynamic  analysis  tools 

•  terminal  interface  routines 

•  file  administrator 

•  command  interpreter 

•  configuration  manager 
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c.  APSE 

The  highest  level  and  broadest  view  is  the  APSE 
itself.  This  includes  a  set  of  advanced  tools  to  support 
all  phases  of  the  life  cycle.  Again  ST C NEMAN  [Kef.  47]  does 
not  specify  specific  tools,  but  does  require  tools  for: 

•  creation  of  data  base  objects 

•  modification 

•  analysis 

•  transformation 

•  display 

•  execution 

•  maintenance  (emphasis  added) 

F.  DSE  CF  TOOLS  AND  STANDABDS 

The  final  guesticn  to  the  manager  regarding  the  use  of 
tools  and  standards  within  a  specific  organization  is  hew 
they  may  be  integrated  to  manage  the  function  cf  mainte¬ 
nance.  Gilb  presents  a  possible  way  to  organize  these  tools 
[Ref.  48].  He  addresses  one  individual  project,  but  the 
authors  feel  that  the  manager  may  use  this  system  to  eval¬ 
uate  a  specific  project  or  the  organization  as  a  whole.  The 
process  goes  through  a  series  of  tables  that  are  designed  to 
determine  what  new  tools  (referred  to  as  techniques)  that 
the  manager  should  actively  seek  out.  Gilb  steps  through  a 
simple  project  to  demonstrate  a  manager’s  process  of  evalua¬ 
tion  of  one’s  objectives,  priorities  (referred  to  as 
quotas),  and  techniques  already  available  within  the  organi¬ 
zation.  Some  calculations  between  the  organization’s  prior¬ 
ities  and  currently  available  tools  demonstrate  areas  where 
the  manager  might  want  to  actively  seen  new  tools. 


90 


There  is  one  caution  in  this  area  though  from  the  DoD 
Joint  Service  Task  Force  Report  [Ref.  31].  No  widely 
accepted  productivity  measure  exists  for  the  various  tools 
nor  combinations  of  tools.  Using  tools  with  which  mainte¬ 
nance  personnel  are  familiar  may  be  the  most  efficient 
utilization  of  personnel  resources  because  it  reduces 
mechanical  activities  and  allows  creative  ones,  but  should 
not  he  limited  to  these  when  additional  tools  would  be 
useful. 

A  standard  emphasizes  where  personnel  need  tc  be 
trained.  An  example  of  a  standards  policy  is  can  be  shewn 
within  the  Department  of  the  Navy.  A  Navy  instruction, 
SECNAVINST  5230.8,  Information  Processing  Standards  for 
Computers  (IPSC)  Program  gives  the  overall  policy  informa¬ 
tion  on  high  order  language  (HOL)  standards,  while 
attempting  to  avoid  the  proliferation  of  local-  or  vendor- 
unigue  standards.  The  objective  is  to  identify,  develop 
and  implement  standards  that  will: 

•  Provide  for  the  greatest  degree  of  compatibility 
between  non-tactical  ADP  systems  and  their  associated 
data  systems. 

•  Facilitate  the  development  of  machine  independent 
software. 

•  Provide  for  efficient  operation  and  utilization  cf  the 
ADP  equipment. 

•  Incorporate  and  make  available  for  general  use  related 

standardization  efforts  of  individual  ADP 

organizations. 

•  Increase  reliability  and  transportability  of  software 
and  facilitate  backup  and/or  contingency  processing. 
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A  more  specific  standard,  MAPTIS*  High  Order  language 
(iOL)  Standard  (OPNAV  P160-S7-94)  [Ref.  49],  while  recog¬ 
nizing  the  wide  variety  of  unigue  problems  to  be  faced 
within  an  organization  as  large  as  the  Navy,  further  sets 
approval/ncnapproval  status  for  the  MAP7IS  program  or.  the 
use  of  software  languages.  The  latest  language  tools  are 
divided  into  fourth  generation  languages,  no n- procedural 
languages  and  guery/retrie val  languages.  An  example  'of 
currently  available  data  management  languages  is  shown  in 
Table  XII  from  this  standard.  (This  table  is  not  intended 
to  be  a  comprehensive  list.)  According  to  this  standard 
[Ref.  49:  p.  4],  it  is  not  intended  to  discourage  the  use  of 
languages  other  than  the  already  approved  COBOL,  FORTRAN, 
E&SIC  and  Ada.  Instead,  it  should  force  commands  to  demon¬ 
strate  the  cost  effectiveness  of  a  new  language  in  the 
specific  situation  and  to  provide  higher  level  authority 
with  information  about  what  and  where  languages  are  being 
used  and  to  provide  information  for  evaluating  similar 
languages. 


t  - 

•MAPTIS  is  an  acronym  for  Manpower,  Personnel  and 
Training  Information  Systems. 
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VIII.  DATA  EVOLUTION 


A.  DATA  AS  A  TOOL 

The  area  of  data  usage  has  two  separate  implications  for 
software  maintenance.  First#  there  is  the  question  cf  how 
the  separation  of  the  data  from  the  application  program 
effects  the  function  of  those  assigned  to  '’maintain"  or 
improve#  keep  up-to-date,  etc.  the  software  system.  The 
second  implication  lies  within  the  research  and  development 
of  the  software  tool  called  a  data  base  management  system 
(DBMS).  Mary  tools  and  methods  are  being  developed  that  can 
aid  in  the  process  and  management  of  th^  software  mainte¬ 
nance  function.  This  can  be  just  one  of  them. 

In  this  day  and  age  of  the  computer,  most  organizations 
are  beginning  to  realize  that  no  matter  what  the  function  cf 
the  organization  (anything  from  product  manufacturing  to 
service-oriented  financing)  #the  information  needed  at  all 
levels  is  an  important  resource.  This  has  created  the 
distinction  between  data  and  information.  There  is  much  raw 
data  available,  but  information  is  that  data  which  is  put 
into  a  useable,  correct,  relevant  and  manageable  form.  Raw 
data  is  useless  until  it  is  formatted  and  made  available. 
Correct  and  relevant  information  is  needed  at  all  levels. 
It  becomes  just  as  important  for  the  supervisor  in  a  bank 
operation  to  know  the  status  of  the  transactions  as  it  is 
for  the  hank  president  to  know  the  cost  and  economies  of  the 
operations  of  the  total  organization. 

The  format  of  this  information  might  be  in  any  form  from 
a  logically  organized  file  drawer  to  a  computer  system  with 
automatic  or  query- driven,  retrievable  information.  with 
more  and  more  data  being  processed  by  any  organization  and 
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computer  hardware  technology  costing  less  and  less,  the  only 
cost  effective  vav  to  process  data  of  a  very  sizeable 
amount,  is  to  process  it  on  the  computer.  This  may  mean 
using  computers  from  very  large  mainframes  tQ  micro  proces¬ 
sors  or  any  combinations  in  between.  There  will  not  be  too 
much  distinction  between  the  size  of  these  computer  systems 
placed  here,  since  the  same  principles  sti.'l  apply,  though 
sc-me  times  to  a  lesser  degree.  The  decision  making  process 
requires  accurate  and  timely  information.  In  the  opinion  of 
the  authors  it  is  becoming  increasingly  apparent  then  that 
the  individual  who  controls  the  information  is  in  control  of 
the  organization.  Thus,  we  as  a  society  are  rapidly  moving 
from  the  Industrial  Ace. 

B.  USE  CF  DATA  BASE  MANAGEMENT  SYSTEMS 

The  need  then  to  manage  and  control  this  data  separately 
and  effectively  within  an  organization  has  created  a  data 
base  environment.  The  DBMS  itself  can  effect  the  success  of 
the  total  package  of  maintenance  tools.  As  Dorahcc  and 
Swearingen  state:  "....database  is  an  essential  requirement 
for  configuration  management  and  for  using  automated  tools 
tc  maintain  software"  [Ref.  4:  p.  5-2].  It  provides  a 
convienient  means  of  storing  test  cases,  providing  error 
history  and  statistics,  and  cataloguing  the  detail  program 
characteristics.  The  data  base  environment  has  alsc  helped 
to  get  a  handle  on  reducing  some  of  the  long-term  mainte¬ 
nance  problems  and  ccsts. 

The  data  base  environment  has  not  always  existed.  It 
has  grown  from  the  recognition  of  the  problems  with  the 
management  of  data.  Analysis  had  shown  that  data  should  be 
handled  separately  from  the  functions  that  the  software  must 
perform.  Today  there  exist  many  levels  of  tnis  separation 
of  data  from  functions  in  the  various  computer  environments. 
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This  development  represents  a  change  not  only  in  software 
but  in  data  processing  management.  The  separation  of  data 
from  function  has  evolved  along  with  the  other  changes  in 
the  data  processing  field,  such  as  hardware  improvements  and 
software  languages.  The  separation  has  created  the  data 
base  environment,  where  various  programs  and  groups  can  have 
access  to  the  same  data  and  which,  if  properly  implemented, 
can  aid  in  the  maintenance  function.  Martin  and  McClure 
[Eef.  25]  have  presented  this  separation  as  a  progression 
through  a  series  of  four  classes: 

•  Files 


•  Application  Data  Ease 

•  Subject  Data  Base 

•  Information  Systems 

Martin  and  McClure  have  specified  only  these  four 
classes  of  environments,  but  the  authors  feel  that  a  fifth 
class  for  the  distributed  data  base  should  be  added.  Each 
level  increases  the  implementation  complexity  of  the  system, 
but  adds  to  the  management  capability  to  handle  greater  and 
more  diverse  amounts  cf  data.  These  five  levels  are  defined 
below  in  a  chronological  order,  but  this  is  not  necessarily 
implying  that  there  must  be  a  chronological  movement 
(classes  I  to  V)  of  the  structure  of  data  at  a  specific 
location,  tut  rather,  that  the  various  combinations  of  these 
environments  can  and  do  exist  at  any  one  time  within  a 
single  organization. 

1.  Class  I  Environment:  Files 


All  early  computer  systems  handled  data  operations 
as  a  file  system.  Systems  were  created  to  accoaplisn  a 
specific  function  and  the  data  description  used  was  embedded 


computer  hardware  technology  costing  less  and  less,  the  only 
cost  effective  way  to  process  data  of  a  very  sizeable 
amount,  is  to  process  it  on  the  computer.  This  may  mean 
using  computers  from  very  large  mainframes  to  micro  proces¬ 
sors  or  any  combinations  in  between.  There  will  not  be  too 
much  distinction  between  the  size  of  these  computer  systems 
Fiaced  here,  since  the  same  principles  still  apply,  though 
sometimes  to  a  lesser  degree.  The  decision  making  process 
requires  accurate  and  timely  information.  In  the  opinion  of 
the  authors  it  is  becoming  increasingly  apparent  then  that 
the  individual  who  controls  the  information  is  in  control  of 
the  organization.  Thus,  we  as  a  society  are  rapidly  moving 
from  the  Industrial  Age. 

B.  USE  CF  DATA  BASE  MANAGEMENT  SYSTEMS 

The  need  then  to  manage  and  control  this  data  separately 
and  effectively  within  an  organization  has  created  a  data 
base  environment.  The  DBMS  itself  can  effect  the  success  of 
the  total  package  of  maintenance  tools.  As  Donahoc  and 
Swearingen  state:  "....database  is  an  essential  requirement 
for  configuration  management  and  for  using  automated  tools 
tc  maintain  software"  [Hef.  4:  p.  5-2].  It  provides  a 
convienient  means  of  storing  test  cases,  providing  error 
history  and  statistics,  and  cataloguing  the  detail  program 
characteristics.  The  data  base  environment  has  also  helped 
to  get  a  handle  on  reducing  some  of  the  long-term  mainte¬ 
nance  problems  and  costs. 

The  data  base  environment  has  not  always  existed.  It 
has  grown  from  the  recognition  of  the  problems  with  the 
management  of  data.  Analysis  had  shown  that  data  should  be 
handled  separately  from  the  functions  that  the  software  must 
perform.  Today  there  exist  many  levels  of  this  separation 
of  data  from  functions  in  the  various  computer  environments. 


within  the  system.  The  problem  was  that  an  organization  was 
not  static  r.or  was  (cr  is)  the  data  being  processed.  As 
more  and  more  systems  were  automated,  major  problems  were 
created.  A  high  level  of  redundancy  of  the  data  was  propa¬ 
gating  throughout  these  different  systems,  creating  diffi¬ 
cult  maintenance  problems  of  data  consistency  and  integrity. 
An  apparently  simple  change  could  propagate  a  chain  reaction 
of  problems.  These  systems  became  very  inflexible,  espe¬ 
cially  when  considering  one  time  reguests.  File  systems 
also  were  very  expensive  to  maintain  [Ref.  25:  p.  118]. 
Often  the  great  amount  of  money  invested  in  existing  file 
systems  and  the  normal  resistance  to  change  have  delayed  the 
movement  to  the  next  level  of  environment.  These  costs  are 
sunk  costs  though  and  should  not  be  considered  since  they 
have  nc  effect  on  the  improvements  or  the  maintenance  of  the 
system.  Examples  of  file  systems  are  VSAM  and  RKS. 

2.  Class  II  Environment:  Application  Data  Base 

The  problems  of  the  data  changing  while  the  function 
stayed  the  same  created  the  need  for  a  data  base  system  to 
help  manage  and  separate  the  data  changes.  The  "data  base" 
term  is  used  in  many  forms  of  literature,  but  it  is  often 
only  the  currently  popular  term  for  a  file  system.  A  good 
definition  from  Martin  and  McClure  is 


....a  shared  collection  of  interrelated  data  designed 
to  meet  the  needs  cf  multiple  types  of  end  users.  It 
can  be  defined  as  a  collection  of  data  from  which  many 
different  end  user  views  can  be  derived  [Ref.  25:  p. 
1171. 


In  any  case  the  key  is  the  storage  independence  cf 
the  data  from  the  application  programs  plus  the  different 
logical  views  allowed  of  the  data.  Any  modification  of  only 
the  data  then  can  be  controlled  independently.  The  class  II 
environment  was  created  guite  naturally  from  the 


process-oriented  design.  Systems  each  started  using  a  data 
base,  fcut  each  application  created  its  own  data  base.  This 
was  easier  to  implement  than  the  next  level,  tut  also 
continued  almost  all  the  same  problems  as  class  I  environ¬ 
ment  with  a  high  redundancy  of  data  that  would  continue  to 
proliferate  as  new  furctions  were  added.  In  addition  to  the 
high  cost  of  buying  this  DBMS  package,  there  would  te  the 
continuing  high  cost  cf  maintaining  the  data.  This  pointed 
up  the  necessity  for  a  Data  Administrator  (DA)  or  Data  Base 
Administrator  (DEA)  to  aid  in  the  planning  and  control  of 
this  organizational  resource.  Some  examples  of  the  commer¬ 
cial  packages  are  TOTAL  by  Cincom  and  IDK3  by  Cullinet, 
which  originally  came  out  in  the  early  1970's.  The  packages 
purchased  for  use  in  this  environment  could  also  be  the  same 
ones  as  those  purchased  for  use  in  the  next  class  III 
environment. 

3.  Class  III  Environment:  Subject  Data  Pases 

In  this  environment  there  is  an  actual  design  of  the 
data  structure  done  independently  of  the  functions  that  must 
he  carried  out  through  the  programming  systems.  Although 
this  is  the  second  environment  to  use  data  bases ,  it  is  the 
first  to  actually  help  reduce  maintenance  costs.  An  over¬ 
head  is  the  initial  time  required  to  do  the  analysis  and 
modeling  of  the  data  requirements,  but  this  can  reduce  the 
time  and  cost  later  cn  in  both  the  development  and  mainte¬ 
nance  cf  application  systems  and  their  interaction  through  a 
single  data  base.  This  environment  not  only  requires  a 
change  in  the  traditional  analysis  methods,  but  also  in  the 
traditional  overall  data  processing  management.  Ideally, 
there  would  be  active  use  of  some  sort  of  DBA  to  maintain 
planning  and  operational  control  of  the  data,  but  there  must 
also  te  upper  management  support  for  this  change  in  organi¬ 
zation.  If  that  is  net  done,  an  energetically  started  class 


Ill  environment  can  quickly  degenerate  into  a  class  II 
environment  [Ref-  25:  p.  123]. 

4.  Class  IV  Environment :  Information  Systems 

This  fourth  class  of  data  base  is  organized  for  the 
purpose  of  fast  retrieval  of  information  rather  than  the 
high  volume  production,  runs,  which  can  work  best  in  a  batch 
mode.  Some  examples  of  these  systems  might  be  IBM’s  SIAIRS 
or  some  of  the  relational  models  such  as  SQL  and  NOMAD, 
which  also  provide  good  query  facilities  for  these  user- 
driven  systems.  These  systems  are  not  difficult  tc  imple¬ 
ment  and  provide  great  flexibility  for  systems  that  require 
fast  retrevial  capabilities.  On  the  other  hand,  they  may 
not  be  efficient  for  systems  requiring  high  volume  trans¬ 
action  processing. 

In  a  case  where  both  retrieval  and  production  runs 
are  needed,  trade-offs  must  be  made  between  the  two  opposing 
requirements.  This  may  be  done  tnrough  a  combination  of 
class  III  and  class  IV  data  bases  where  data  is  passed 
through  an  "extractor”  program  [Ref.  25:  p.  127].  This 
would  create  two  separate  data  bases  where  each  is  efficient 
for  its  specific  function,  but  data  also  must  be  controlled 
and  passed  between  the  data  bases  on  some  schedule.  This 
schedule  may  be  on  one  or  many  possible  conditions:  online, 
offline,  triggered  by  an  event,  ad  hoc  or  even  real  time. 
Careful  attention  must  be  paid  to  ensure  the  integrity  of 
both  systems  and  the  timing  of  each  process.  The  major 
problem  is  that  if  both  data  bases  are  not  locked  from 
external  use  as  updates  are  applied  to  both  files  simultane¬ 
ously,  the  data  bases  could  both  become  only  partially  accu¬ 
rate.  An  alternative  approach  might  be  to  maintain  a  single 
data  base  and  choose  a  system  that  was  less  efficient  for 
either  individual  function,  retrevial  or  production,  tut 
adequate  for  both.  This  may  be  done  by  using  multiple 
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indexes  cr  an  inverted  list.  Only  a  thorough  evaluation  of 
the  individual  situation  can  determine  tne  best  trade-off. 

5.  Class  V  Environment;  Distributed  Data  Base 

In  this  age  cf  the  merging  of  the  technologies  of 
computers  and  communications,  another  environment  for 
computer  data  most  definitely  is  the  use  of  data  distributed 
throughout  a  computer  network.  Data  used  at  one  specific 
installation  is  handled  through  one  or  more  of  the  classes  I 
through  IV.  Data  can  be  passed  as  files  from  one  computer 
system  tc  another,  as  needed.  In  the  case  of  on  organiza¬ 
tion  whose  functions  are  distributed  among  widely  separate 
geographic  locations,  pieces  of  data  are  contained  at  these 
separate  sites  with  a  need  for  it  to  be  managed  by  a  single 
system.  A  network  data  manager  has  been  proposed  for  this 
by  a  COCAS YL  committee  to  be  another  layer  of  their  DEBS. 
Its  extension  would  be  called  Network  Data  Base  Management 
System  (NDBMS) .  This  would  be  another  type  of  option  that 
could  be  implemented  cn  the  GEMS  that  would  manage  the  data 
resource  reguested  cn  distant  systems.  The  major  drawback 
for  this  CODASYL  NEEMS  is  that  it  requires  a  homogenous 
computer  system. 

Another  and  more  well-known  attempt  in  this  direc¬ 
tion  is  the  System  for  Distributed  Data  3ases  (SBD-1)  by 
Computer  Corporation  of  America.  This  system  was  designed 
foe  the  Department  of  Defense’s  ARPANET.  It  is  designed  to 
handle  the  problems  in  relation  to  a  global  data  directory, 
conflicts  with  possible  deadlocks,  and  problems  cf  effi¬ 
ciency.  The  replication  of  data  at  different  sites  is 
permitted,  if  it  is  determined  that  duplication  is  more 
efficient  than  the  transmission  costs  involved  [  Bef .  50]. 

Either  of  these  systems  allows  a  choice  for  the 
organization  that  has  many  types  of  data  and  a  requirement 
to  access  that  data  at  different  sites  in  different  ways. 


The  individual  who  is  the  network  data  manager  for  these 
systems  will  have  his  or  her  hands  full  maintaining  these 
types  of  future  systems. 


C.  IHEIVIDOAL  DATA  HEEDS 

All  organizations  would  not  necessarily  benefit  from 
moving  to  higher  and  higher  levels  of  dat^  systems.  There 
are  organizations  whose  use  of  the  data,  such  as  in  very 
high  vclume  transaction  processing,  may  even  best  be  served 
by  file  systems.  But  when  different  ways  of  locking  at  the 
same  data  are  needed,  the  data  base  system  is  needed.  The 
most  frequent  implementations  today  are  combinations  of 
class  III  and  class  IV.  Class  V  may  be  a  reality  in  the 
future,  but  for  now  it  is  more  of  a  concept. 
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IX.  CO NCLOSIONS^ RECOMMENDATIONS 


A.  TEE  f ROBLEN 

The  maintainer' s  chief  skill,  like  the  surgeon's,  is  rot 
in  making  desirable  changes  cut  in  avoiding  unaesireatl e 
ones.  lAny  fool  can  take  out  art  appendix;  the  trick  is 
to  take  it  out  without  killing  the  patient.)  [Ref.  9: 

?.  ix] 

As  has  been  described  the  task  cf  computer  software 
maintenance  is  no  easy  undertaking  and  consequently  neither 
is  the  function  of  the  maintenance  manager.  A  general 
framework  for  analyzing  this  task  has  been  presented  tc  aid 
in  understanding  the  process. 

The  central  focus  of  this  thesis  has  been  that  software 
evolves.  This  thesis  has  examined  the  internal  and  external 
factors  involved  in  the  ability  of  an  organization  to 
respond  and  direct  the  evolutionary  demands  on  software.  In 
an  effort  to  help  the  software  manager  understand  software 
evolution,  the  authors  have  concentrated  on  four  topics. 
Each  topic  serves  as  an  element  of  the  paradigm  of  evolu¬ 
tion,  building  upon  the  last  toward  the  goal  of  controlling 
software  evolution. 

•  Historical  Perspective:  To  predict  software  evolu¬ 

tion,  the  software  manager  must  understand  the  present 
and  past  states  of  the  software  system.  That  under¬ 
standing  is  gained  through  the  collection,  retention 
and  analysis  of  data  about  software  evolution. 

•  The  Ability  to  Predict:  Once  the  historical  perspec¬ 

tive  is  achieved,  the  software  manager  may  predict  how 
various  internal  and  external  factors  will  influence 
software  evolution. 


•  The  Focus  of  Control:  Manpower  is  the  critical 

resource  in  software  evolution,  and  thus  efforts  to 
control  the  personnel  resource  will  yield  the  most 
sutstantial  influence  on  software  evolution.  The  key 
to  successful  control  of  tne  personnel  resource  is 
through  understanding  the  nature  of  the  maintenance 
programmer  and  how  this  function  is  performed. 

•  The  Means  of  Control:  There  are  several  ways  to 

control  the  influence  of  personnel  on  software  evolu¬ 
tion.  The  authors  chose  to  focus  on  the  use  of  soft¬ 
ware  tools,  the  enforcement  of  standards  and  the 
integration  of  data  as  the  means  of  control  that  would 
offer  the  most  positive  long-range  benefits. 

E.  CCNC1USIOHS 

1 •  Historical  Data  Collection 

tfhile  data  often  exists  with  which  a  software 
manager  may  develop  a  historical  perspective,  that  data  is 
generally  unusable  due  to  a  number  of  deficiencies. 
Fundamental  concepts  are  not  universally  defined.  The  defi¬ 
nition  cf  "software  maintenance"  itself  is  debated. 
Concepts  such  as  "program  complexity"  and  "programmer 
productivity"  are  defined  in  largely  subjective  terms  and 
open  to  interpretation.  Sven  a  physical  quantity  like 
"lines  cf  code"  cannot  be  consistently  defined. 

Without  fundamental  concepts  rigorously  defined, 
metrics  to  measure  the  qualities  of  the  software  and  of  the 
environment  cannot  be  established.  The  collection,  categor¬ 
ization  and  analysis  cf  data  is  virtually  impossible  without 
a  suitable  set  of  software  metrics.  The  characteristic 
elements  of  a  software  system  discussed  in  Chapter  IV  were 
presented  in  a  highly  subjective  manner,  and  tend  to  reflect 
the  imprecise  nature  cf  contemporary  software  metrics. 


Cnee  a  suitable  set  of  software  metrics  for  estima¬ 
tion  is  derived,  data  may  be  collected  and  analyzed  to 
establish  the  historical  perspective  of  the  software  system. 

2.  Predicting  Software  Maintenance: 

The  state  of  the  art  of  software  maintenance  cost 
estimation  is  hobbled  by  an  incomplete  understanding  cf  the 
factors  that  influence  software  evolution.  Despite  exten¬ 
sive  research  into  software  cost  estimation,  existing  devel¬ 
opment  models  yield  estimates  that  are,  at  best,  within  20* 
of  the  actual  cost  roughly  80$  of  the  time  [Ref.  Is  p.  521]. 
Models  designed  to  estimate  software  development  costs  tend 
to  be  even  more  inaccurate  when  applied  to  software  mainte¬ 
nance  [Ref.  28:  p.  D-16].  Thus,  a  software  manager  is 
forced  to  employ  several  techniques  and  models  when 
attempting  to  predict  future  software  evolution  and  estimate 
the  resources  required  to  implement  that  evolution. 

3 .  Personnel 

In  a  final  recognition  of  the  necessity  of  the  main¬ 
tenance  function,  managers  must  value  their  maintenance 
personnel.  This  is  a  function  that  will  continue  to  receive 
more  attention  as  the  cost  of  the  maintenance  function  is 
shown  to  be  a  large  percentage  of  the  software  life  cycle. 
The  goal  is  to  have  tetter  and  more  productive  maintenance 
personnel. 

There  are  three  major'  areas  that  must  not  be 
neglected.  These  are  training,  incentives  and  career 
progression. 

•  Maintenance  personnel  must  not  be  neglected  when  new 
techniques,  hardware,  software,  etc.  classes  are  being 
given.  They  too  must  be  included  so  they  may  be 
prepared  to  meet  the  demands  of  the  future. 
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•  Incentives  can  come  in  many  forms.  Train 
may  te  an  incentive  to  some  career-minded 
Adequate  environment  (working  spaces) ,  t 
support  to  do  the  job,  provide  a  great  i 
can  show  the  maintenance  programmer  that 
really  does  count. 
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4 .  Tools 


In  the  push  to  make  use  of  tools  in  a 
environment,  the  past  is  most  definitely  pro 
standards  enforced,  the  tools  used,  the  struct 
the  development  of  the  system  will  directly  eff 
even  te  attempted  in  the  maintenance  phase.  Wh 
ware  to  te  maintained  is  an  old,  assembler  langu 
mented  system,  remedial  steps  must  be  t 
immediately  to  have  the  working  tools  needed  i 
when  the  system  bombs.  These  remedial  steps 
current  documentation  on  these  systems  can  have 
benefit.  It  becomes  a  self  defense  measure  t 
disaster  as  well  as  providing  initial  training  £ 
tenance  programmers.  An  example  of  the  ver 
available  for  this  retrofit  is  presented  by  S 
[Ref.  38], 
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The  progression  ideally  would  assume  that  the  effort 
in  the  development  group  would  be  toward  the  use  cf  higher 
and  higher  level  languages  with  the  comparable  larger 
numbers  of  tools  and  environments  available.  This  assumes, 
as  has  been  shown,  that  the  progression  to  fourth  generation 
languages  with  their  package  of  integrated  tools  will  allow 
a  more  efficient  maintenance  function  in  the  future. 

The  one  recommendation  the  authors  make  in  this  area 
would  be  for  o rgan i2ations  to  make  better  use  of  user’s 
groups  tc  discuss  individual  problems  and  explore  the  appli¬ 
cability  cf  now  software  tools.  Specific  communities 
containing  unique  implementations,  specialized  hardware, 
unigue  or  obsolete  languages,  or  combinations  of  these  would 
be  aided  immeasurab lly  by  contact  on  a  regular  basis.  This 
interaction  could  take  the  form  of  phone  calls,  conferences, 
newsletters,  networking,  electronic  bulletin  boards,  etc. 
Such  an  interaction  wculd  enhance  data-processing  cohesive¬ 
ness  and  offer  a  ready  forum  for  the  exchange  of  problems 
and  their  solutions. 

5 .  Summary 

A  basic  understanding  cf  this  software  evolution  is 
required  for  the  maintenance  manager  to  be  able  to  antici¬ 
pate  the  future;  not  with  crisis  management  and  the  dread  of 
impending  catastrophe,  but  with  confidence,  anticipating 
where  problems  may  arise  and  how  to  meet  them.  Armed  with 
an  accurate  software  history,  the  software  manager  may 
predict  with  accuracy  future  directions  for  the  software 
system  and  estimate  the  resources  required  tc  evolve  in 
those  directions. 


APPENDIX  A 
TOOLS 

A.  TOOL  CATALOGS  AND  REFERENCES 

Listed  below  are  tool  catalogs  and  references  which  may 
he  of  seme  use.  They  contain  information  on  tool  avail¬ 
ability,  functions  and  features,  sources,  cost,  etc.  from 
[Ref.  51:  p.  E-1] 

1.  "CATAPRO  Directory  of  Software,"  DATAPRO  Research 
Corp.,  McGraw-Hill. 

2.  "Software  Development  Tools",  Special  Publication 
500-3S,  Raymond  C.  Houghton,  Jr.,  National  Bureau  of 
Standards,  March  1982. 

3.  "Federal  Software  Exchange  Catalog",  Federal  Software 
Exchange  Center,  General  Services  Administration, 
Report  No.  G S A/ AD T SC- 82/1 ,  January  1982. 

4.  "FCSC  Conversion  Tools  Survey",  Federal  Conversion 
Support  Center,  General  Services  Administration, 
Report  No.  GSA/FCSC- 82/00 1 ,  October  1982. 

5.  Software  Tool  Catalog",  Federal  Software  Testing 
Center,  General  Services  Administration,  Report  No. 
FCTC-82/013,  April  1982. 

6.  AOERBACH  Technology  Reports,  AUERBACH  Publishing 
Inc.,  1982. 

7.  "International  Directory  of  Software,  1980  -  81", 

CUYB  Publications,  England,  1980. 

9.  "The  EDP  Performance  Review  --  Ninth  Annual  Survey  of 
Performance-Related  Software  Packages",  Applied 
Computer  Research,  Volume  9,  Number  12,  December 


9.  "Software  Engineering  Automated  Tools  Index", 
Software  Research  Associates,  California,  1981. 

10.  "Software  Tools:  Catalogue  and  Recommendations",  TRW 
Eefense  and  Space  Systems  Group,  1979. 

11.  "NES  Software  Tools  Database",  Raymond  C.  Hcughtcn, 
Jr.  and  Karen  A.  Oakley,  NBS-IR-80-2159,  National 
Bureau  of  Standards,  October  1980. 

12.  "ICP  Software  Directory  -  Data  Processing 
Management",  P.O.  Box  2350,  Clinton,  Iowa  52732. 

13.  "AIAA  Computer  Systems  Committee  Software  Tools 

Survey",  Data  &  Analysis  Center  for  Software,  Rome 
Air  Development  Center  (R ADC ) ,  ISISI,  Grif fiss  Air 
Force  Base,  NY  13441. 

14.  "Software  Tools  Survey",  Federal  Software  Testing 
Center,  General  Services  Administration,  Report  No. 
0 SD/FSTC- 83/015,  June  24,  1983. 

B.  SOFTWARE  MAINTENANCE  COST  ESTIMATING  MODELS 

The  purpose  of  this  section  of  the  appendix  is  to 
briefly  summarize  selected  software  maintenance  cost  estima¬ 
tion  models.  A  rigorous  analysis  or  comparison  of  the 
models  will  not  be  attempted. 

1.  Software  Lifecycle  Model  -  SLIM 

This  model  is  available  from  Quantitative  Software 
Management,  Inc.  An  automated  system,  SLIM  operates  on 
Hewlett  Packard  equipment  and  is  in  use  at  the  Naval 
Electronic  Systems  Command.  SLIM  is  derived  from  L. 
Putnam’s  Life  Cycle  Model  as  represented  by  the  Rayleigh 
distribution.  {See  Figure  2.3).  Courses  on  the  the  use  of 
SLIM  are  offered  through  the  Department  of  Defense  Computer 
Institute,  Washington,  D.C. 

2.  Constructive  Cost  Model  -  CCCOMO 


The  CCCCMO  model  was  developed  by  3arry  W.  3oehm  and  is 
presented  in  great  detail  in  his  book.  Software  Engineering 
l£2£Oji£s,  [fief.  1].  COCOMO  is  easy  to  use  with  ruiercus 
tables  from  which  the  estimator  may  readily  derive  the 
required  parametric  values.  The  model  algorithm  is  well- 
discussed  and  lends  itself  well  to  automation. 

3.  The  Scope  of  Effort  Algorithm 

This  model  was  developed  by  G.S.  Hoppenstand,  IT,  USN 
and  1.  T.  Nowak  [fief.  21]  at  the  Naval  Security  Group 
Activity,  Skaggs  Is.,  California  specifically  for  estimating 
software  maintenance.  Their  rather  unique  approach  is  to 
analyze  the  complexity  of  a  given  software  system,  then 
derive  the  number  of  "steps"  required  to  complete  an  average 
maintenance  task.  (This  approach  is  possible  largely 
because  the  effort  of  studying  the  existing  system  and  is 
the  single  largest  task  in  performing  the  software  mainte¬ 
nance  -  figure  2.1.)  Their  model  then  predicts  the  number 
of  "steps"  a  military  programmer  or  given  experience  can 
complete  per  year.  Thus,  the  billet  requirements  may  be 
calculated  for  a  given  system. 

4.  The  Model  for  Estimating  Tactical  Software  Maintenance 
Requirements 

This  model  was  developed  by  W.  H.  Merring,  III,  Capt, 
USMC  as  a  master’s  thesis  at  the  Naval  Postgraduate  School, 
Monterey,  California.  The  Merring  model  [fief.  22]  employs 
"bebugging",  a  technique  of  seeding  a  program  with  inten¬ 
tional  errors  to  determine  the  error  rate,  the  detectability 
of  errors,  and  the  maintainability  of  the  program.  This 
technique  is  used  to  estimate  the  corrective  maintenance 
workload.  Enhancement  maintenance  is  estimated  using 
Halstead's  Effort  Metric  [Ref.  24]  as  a  measure  of  program 
complexity.  Halstead's  metric  has  been  shown  to  be  effec¬ 
tive  at  estimating  maintenance  costs  in  unstructured  code 
[Ref.  4:  p.  2.14]. 
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